FuelLabs/sway: a Rust-like language for the Fuel blockchain

What Sway is for, and who it excludes

Sway is a language developed for the Fuel blockchain, and the README says it is heavily inspired by Rust. That single sentence sets the audience. If you write Rust, the syntax, the module layout and the error style will look familiar. If you write Solidity, the mental model transfers less cleanly, because the toolchain around the language is a Rust workspace rather than a JavaScript or Python package.

The repository confirms the Rust framing: the workspace members are forc, forc-pkg, forc-plugins/*, forc-test, forc-util, sway-ast, sway-core, sway-error, sway-features, sway-ir, sway-lsp, sway-parse, sway-types, sway-utils, swayfmt and test. A compiler front end (sway-parse, sway-ast), a middle layer (sway-core, sway-ir), diagnostics (sway-error) and editor support (sway-lsp) are all separate crates. This is a compiler project with a package manager attached, not a scripting layer over a virtual machine.

The exclusion is the important part. Sway compiles for Fuel. Nothing in the README suggests it produces bytecode for another chain, and the documentation links point at docs.fuel.network and the Sway Book. If your contracts must run on a different network, this is not a tool you can evaluate on merit alone; the target chain decides the language.

How the compiler and toolchain are split

The architecture visible in the repository is a conventional compiler pipeline with an unusual amount of tooling shipped alongside it. Parsing and AST construction live in sway-parse and sway-ast. Semantic analysis, type checking and lowering live in sway-core, with an intermediate representation in sway-ir. Errors are collected in sway-error rather than scattered through the passes. Formatting is its own crate, swayfmt, and the formatter is also exposed as a plugin, forc-fmt.

The plugin directory is where the developer-facing surface lives: forc-debug, forc-doc, forc-fmt, forc-lsp, forc-migrate, forc-publish and forc-tx. Each is versioned in lockstep with the compiler through workspace.dependencies, all pinned at 0.72.1 in the Cargo.toml shown here. That lockstep is a design decision worth noting: upgrading the compiler moves the formatter, the language server and the migration tool together, so a partial upgrade is not the intended path.

sway-lib-std is a workspace member, and the README points to standard library documentation built from the default branch. The examples directory shows the language surface being exercised: arrays, enums, match expressions, nested storage variables, configurable constants, multi contract calls, native asset, msg_sender, hashing, identity, option and a liquidity_pool. There is also a cei_analysis example, which suggests checks-effects-interactions analysis is part of the compiler's concerns rather than a lint you bolt on.

Building forc from source

The README is explicit that building from source is for developing the Sway compiler and toolchain, not for writing contracts. For contract development it points at the released Sway Book. If you do want the compiler itself, the build is a normal Cargo build, and the README gives the exact sequence.

First, install the Rust toolchain from rust-lang.org and pin it to stable:

rustup default stable

Then make sure the Cargo bin directory is on your PATH. The README says to add this line to ~/.profile and restart the shell session:

export PATH="${HOME}/.cargo/bin:${PATH}"

Clone the repository and build the workspace:

git clone [email protected]:FuelLabs/sway.git
cd sway
cargo build

The README gives one confirmation step. Running forc through Cargo should print its help output:

cargo run --bin forc -- --help

That is the whole documented path. Everything else in the repository goes through just, and the justfile lists the recipes. Note the first line of the justfile: the default recipe is just --list --unsorted, so running just with no arguments prints the available recipes instead of doing work.

The justfile is the real command surface

The README spends one line on just and points at the upstream project. The justfile is more informative than that line suggests, and it is where a contributor will actually spend time.

The recipes are grouped. Under ci, install-ci-check installs cargo-sort, cargo-generate and cargo-udeps from crates.io after a confirmation prompt, and ci-check runs bash ./ci_checks.sh. Under automation, update-fuel-dependencies runs bash ./update_fuel_dependencies.sh, update-contract-ids runs bash ./test/update-contract-ids.sh, and bisect-forc takes a path and a command and delegates to scripts/bisect-forc/bisect-forc.sh. Under benchmark, benchmark runs bash ./benchmark.sh and benchmark-tests runs bash ./test/bench.sh.

The performance group is the one that tells you what the project cares about. The alias pe2e expands to perf-e2e, which runs cargo r -r -p test -- --release --kind e2e --perf-only --perf with an optional filter, collecting gas usages and bytecode sizes from end-to-end tests. The alias pil expands to perf-in-lang, which does the same for in-language tests and writes results into ./test/perf_out/ with a timestamp and the current branch name in the filename. Gas usage and bytecode size are treated as first-class regression signals here, which is the right instinct for a compiler whose output runs on a metered chain.

One caution: several of these recipes carry a [confirm(...)] attribute, meaning just will prompt before running them. That is a deliberate guard, not a bug, and it matters if you script them.

Where Sway is the wrong tool

The versioning story is the sharpest limitation, and the README raises it itself. Documentation URLs use three labels: latest redirects to the most recently published Sway release, vX.Y.Z is built from that exact release tag, and master is built from the default branch and may describe unreleased behavior. The README then states plainly that these are Sway documentation versions, not Fuelup channel names, and that they do not identify the toolchain activated on a Fuel network.

That means a page you read under latest can describe a compiler that is not the one a named network channel expects. The README's own remedy is to check the compiler you are running with forc --version and consult the Fuelup channel documentation when selecting network-compatible tooling. There is a second gap of the same kind: the Stable Sway and Forc pages on docs.fuel.network are published by FuelLabs/docs-hub from an explicitly selected release, and that selection can differ from both the newest upstream release and the compiler in a named Fuelup channel. Three sources of truth, no automatic reconciliation.

A second limitation is the release cadence implied by the tags. v0.71.2, v0.72.0 and v0.72.1 are all pre-1.0, and the workspace version tracks them. Pre-1.0 compilers change. forc-migrate exists as a plugin, which is a reasonable signal that source-level migrations are expected rather than exceptional.

Finally, if you want a language with a large contract ecosystem and years of audited patterns, Sway is not that. The examples directory is a teaching surface, not a body of production code you can copy.

Sway against writing Rust directly

The obvious comparison is not another smart contract language; it is Rust itself. Sway is written in Rust, borrows Rust syntax, and the README says it is heavily inspired by Rust. So why not compile Rust for Fuel?

The difference in approach is visible in the repository layout. Sway has its own parser, its own type system and its own IR, and it ships a package manager (forc-pkg), a formatter (swayfmt), a language server (sway-lsp) and a test runner (forc-test) as part of the same workspace. Those components exist because the language is designed around contracts: storage variables, configurable constants, contract IDs and multi contract calls appear as first-class examples rather than library patterns.

A Rust program targeting the same chain would have to reach storage, assets and cross-contract calls through whatever bindings the runtime exposes, and the compiler would have no reason to treat gas usage or contract storage layout as something to reason about. The perf-e2e and perf-in-lang recipes show that Sway's compiler tracks gas and bytecode size as outputs of the compilation itself. That is the substantive difference: not syntax, but what the compiler knows about the target.

The cost is the ecosystem. Rust has crates.io, decades of tooling and a stable language. Sway has a pre-1.0 toolchain, a smaller standard library and documentation that the README admits can drift from the compiler you are running.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-28, the same date as the v0.72.1 tag. The previous release, v0.72.0, is dated 2026-07-27, and v0.71.2 is dated 2026-05-26. That is a steady cadence across the recent window.

Upgrade cost is not zero, and the structure explains why. Every internal dependency is pinned to the workspace version, so forc, forc-pkg, forc-test, forc-util, the seven forc plugins and the sway-* crates all move together. You cannot take a new formatter without taking the compiler that goes with it. The forc-migrate plugin is the documented place to look when source has to change, though the README does not describe what it migrates or how it is invoked; the plugin's own documentation is the place to check.

Licensing is Apache-2.0, declared in Cargo.toml as license = "Apache-2.0" and present as a LICENSE file at the top level. The workspace also declares a SECURITY.md, which is where the project says to look for vulnerability reporting. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to state changes; if you modify the compiler and distribute it, the notice obligations apply. That is a description of the licence text, not legal advice, and any deployment that matters should be reviewed by someone qualified to review it.

Editorial conclusion

Adopt Sway if you are already targeting Fuel and want Rust syntax, a package manager, a formatter, a language server and a test runner in one toolchain. Do not adopt it as a general-purpose language: it compiles for Fuel, and the README is explicit that the compiler you have is not necessarily the compiler a named network channel expects. Before writing anything, run forc --version and compare it against the Fuelup channel you intend to deploy to, because the documentation labels (latest, vX.Y.Z, master) do not identify a network toolchain.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes