Fe: a Rust-like smart contract language that says it is not production-ready

What Fe is, and the status line the README leads with

Fe is described as a Rust-like, statically typed language for the Ethereum Virtual Machine, with explicit effects, message-passing contracts and an integrated toolchain. The Rust resemblance is the hook for most engineers: familiar syntax, static types, and a build system that is Cargo, so the dependency and workspace tooling is not a second thing to learn.

What the language adds is explicit effects and message passing as first class ideas rather than runtime surprises. On an EVM target those are not cosmetic. Calls between contracts are the place where reentrancy and unexpected control flow live, so making a contract's message-passing behaviour part of its type structure is a design choice with security weight behind it.

The first thing the README says, before anything else, is the status: Fe 26.x is not production-ready, with a pointer to the Fe 26 release announcement for context. That framing matters more than any feature list. This is a language with a real compiler, a real language server and a real test harness, but its own maintainers are declining to call the current line ready.

The project is not archived and the last push was on 2026-10-15. Releases came in tight succession in September: v26.4.1 and v26.4.0 on 2026-09-30, and v26.3.0 on 2026-09-16. That cadence points at active work rather than a finished product, and the 26.x numbering means the line is expected to keep moving.

Installing with feup, and the first thing the compiler gives you

Installation is a single installer script piped to a shell:

curl -fsSL https://raw.githubusercontent.com/argotorg/fe/master/feup/feup.sh | bash

That is convenient and it is also the whole security story of the install: you are executing a script fetched over the network at install time from the default branch. Anyone who cares about supply chain review in their toolchain should read feup/feup.sh first or use one of the other installation options described at fe-lang.org.

After install, the compiler is the fe binary. The command reference lives in CLI.md, and the repository does not duplicate it in the README, which is the right call for a CLI that is still changing shape across minor versions.

A first real use means writing a .fe contract and compiling it. The workspace includes a language server, so an editor with LSP support is part of the intended workflow rather than an afterthought, and the top level .zed/ and .vscode/ directories suggest the maintainers use both Zed and VS Code.

For anyone building the compiler itself rather than contracts, the test entry point is Cargo:

cargo test --workspace

Optimized runs use cargo nextest run --cargo-profile test-release --workspace, which is also what CI and make test use. Snapshot tests go through insta, with cargo insta review for inspection and cargo insta accept --workspace to accept pending snapshots.

Compiler architecture: parser, HIR, MIR, resolver, codegen

The crates/ directory is not a monolith. The workspace manifest names the stages and their internal crate names, and the split is a familiar compiler pipeline rather than a Fe invention: fe-parser produces a parse tree, fe-hir lowers it into a high level IR, fe-mir handles the mid level IR, and fe-codegen emits the final output.

Around that core sit the pieces you would expect from a project that treats tooling as part of the product. There is a fe-driver, a fe-resolver, a fe-language-server, a fe-semantic-indexing crate for editor queries, a fe-fmt formatter, a fe-web target, and test helpers in fe-test-utils. Two entries stand out for anyone reasoning about how the compiler is verified: trace-facts and matchcov, where matchcov is pinned as an external version 0.2.0 while most others are path dependencies inside the workspace.

Incremental work runs on salsa 0.20, and the edition is 2024. The presence of a trace-facts crate is worth a second look for anyone auditing the compiler, because the project appears to be investing in tracking facts through the pipeline rather than treating that as an implementation detail.

Two ingot directories sit beside the crates. ingots/core/ holds the core ingot, built into every compilation, and ingots/std/ holds the Fe standard library. The core ingot being mandatory is a design decision with consequences: it is always in your compilation, so it is always in your dependency surface. Release notes are handled by eisenbote, configured in eisenbote.toml, which consumes fragments from newsfragments/.

WebAssembly support is partial and the Makefile shows exactly where the line falls

The build system draws a boundary that says more about the architecture than any prose would. Core crates are checked for wasm32-unknown-unknown:

cargo check -p fe-common -p fe-parser -p fe-hir --target wasm32-unknown-unknown

And the filesystem dependent crates, fe-driver and fe-resolver, are checked separately for wasm32-wasip1, because WASI is what provides the filesystem. The targets split cleanly: parsing, HIR and common utilities are portable to a browser style target, while the driver and resolver need real file access.

There is also a docker-wasm-test target that adds the wasm32-unknown-unknown target to a rust:latest container and runs cargo test for fe-common, fe-parser and fe-hir on it, and a docker-test target that runs the full cargo test --workspace inside rustlang/rust:nightly on a nightly toolchain.

If your interest in Fe is a browser playground or an editor that runs the compiler in a page, that interest is partly supported today: the front half of the pipeline is portable and the back half is not. Coverage runs through cargo tarpaulin --workspace --all-features.

One more build step is easy to miss. The tree-sitter grammar sources, parser.c, grammar.json, node-types.json and the src/tree_sitter/ directory, are not tracked in git and are regenerated at build time from grammar.js. The treesitter-generate target runs npm ci --ignore-scripts, rebuilds tree-sitter-cli and generates with --abi=14, and make test depends on it so that the grammar test in crates/parser/tests/tree_sitter_parse.rs parses every .fe fixture against the freshly generated parser.

Where Fe is the wrong tool right now

The first limitation is the one the project states for itself. Fe 26.x is not production-ready, and there is no way to read around that. For a team shipping value-bearing contracts, that alone ends the discussion unless you are prepared to own the compiler as part of your risk.

The second is the moving target. Three releases in September 2026, a 26.x line the project flags as not ready, and a CLI whose reference lives in a separate file that changes with it, all point to a surface you will be re-reading. The explicit effects and message passing model is the kind of design that earns stability slowly, since the escape hatches people rely on tend to get designed away over several releases.

Third, adopting a language means adopting its standard library. ingots/std/ is part of this repository rather than a large independent ecosystem, so the set of available libraries and their maturity is a direct function of this one project's pace. That is manageable for a contract language, where the standard library is mostly primitives, and it is a real cost for anyone expecting to reach for a crypto math library off the shelf.

Fourth, the test story leans on snapshot testing. insta is the right tool and it also means the correctness bar for language server and formatter output is partly a diff against a recorded expectation, which is cheap to maintain and easy to accept without reading.

The alternative is to stay in Solidity or Vyper and lose the type structure

The realistic comparison is not another EVM language so much as staying with what is already deployed tooling for, which means Solidity or Vyper.

The difference in approach is specific. Fe makes cross-contract messaging explicit, while its Rust-like design offers an alternative model for teams considering a new smart contract language. An established EVM language may offer more familiar tooling, experienced contributors and reusable libraries, at the cost of a contract model that does not make effects and cross-contract messaging explicit in the same way.

Fe's Rust-like surface is also a genuine difference for the hiring question. An EVM team that already writes Rust can read and review Fe far faster than Solidity, and the Cargo workspace plus language server means local tooling is familiar rather than bespoke.

So the honest framing: Fe buys compile time guarantees and reviewer familiarity with Rust at the cost of a young ecosystem and a not production ready label. That is a good trade in a research spike and a bad one for a launch.

Licence, governance and what to check before committing

Fe is licensed under the Apache License, Version 2.0, with the text at LICENSE-APACHE. For a language and compiler that means you can vendor it, modify it and ship it, with the notice and patent conditions Apache-2.0 carries. That is a permissive grant, and it matters here because the compiler is auditable: an operator who is nervous about a not production ready language can read the code, and the licence does not stand in the way.

Contribution norms are stated plainly. Non-trivial language or architecture changes are supposed to start as a discussion on GitHub or Zulip, while bug fixes and small improvements can go straight to a pull request against master. That is a reasonable split, and it also means design changes have a slower path, which is a feature for a language and a delay for whoever needs one.

There is public funding configuration at funding.json, so the project takes money, which is worth noting only because it affects how you read the roadmap rather than the licence terms.

Before adopting, check three things: which version you are actually installing, since the 26.x line is flagged; whether ingots/core/ and ingots/std/ contain what your contract needs, given the core ingot is compiled in every time; and whether the WASM split matters to you, which it does if you expected a browser side compiler.

Editorial conclusion

Adopt Fe if you are experimenting with EVM contracts and want explicit effects and message passing in the source language rather than working around a language that lacks them, and if you can absorb a toolchain that the project describes as not production-ready for Fe 26.x. Do not point value-bearing mainnet deployments at it on that basis. Verify first which version you actually get, since the README marks the whole 26.x line as not production-ready and points to a Fe 26 release announcement for context, and confirm that the ingots you rely on exist in ingots/core/ and ingots/std/ before writing around them.

Frequently asked questions

Official sources

1. argotorg/fe on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases