Iterate Faster in Rust: How blaze Compresses the cargo Rebuild Loop for Engineering Teams
The interval between editing one function and seeing the effect in a live process is where Rust iteration gets expensive. blaze targets exactly that interval: it runs beside cargo, keeps the project compiled in memory, and after an edit recompiles only the changed functions instead of producing the whole program again. This guide is written for developers and technical leads who want a concrete picture of what to install, what the first run feels like, where the published timings come from, and which guardrails should stay in place before a team puts it in front of a real repository.
What changes in the edit-build-run loop
The premise is narrow and deliberate. A project stays compiled in memory, and a change to a single function is written into the program cargo already built, rather than linking that program again from scratch. A program that opts in can take the new code while it keeps running. The two visible consequences for daily work are that, after a function changes, rebuilding returns in milliseconds, and with live edits, saving a file reaches a running program in About 20 ms.
Nothing about cargo's role is being taken away. It is an incremental layer next to the existing workflow, not a fork of it, and the rest of this article shows how that plays out in setup, measurement and team policy.
Setup: placing blaze next to an existing toolchain
- Fetch and run the installer with
curl -fsSL https://raw.githubusercontent.com/indexable-inc/blaze/main/install.sh | sh. - Confirm your platform. Support covers macOS on Apple silicon and Linux; on Windows every build remains cargo's.
- Let the toolchain settle. Whether Rust is installed or not, blaze downloads the Rust it builds with once (about 100 to 135 MB) or uses rustup's toolchain.
- If the default channel does not suit your environment, choose another: other installation paths exist if crates.io or Nix is preferred.
- Open any Rust project and verify that the wrapper answers with the behaviour you already expect from cargo.
First run and the command surface
In any Rust project, blaze run behaves like cargo run, blaze test like cargo test, and blaze build like cargo build. Muscle memory transfers unchanged, which is the main reason a pilot can be run without retraining anyone.
Expect the first build to differ from every build after it: the first build runs cargo, then waits a few seconds for blaze to load the project. After that, when a function changes, rebuilding returns in milliseconds, and the Finished line reports [ra-jit], blaze's engine, so you can tell which path served the build. Other cargo commands pass straight through to cargo, and where cargo is installed, cargo blaze run is the same as blaze run.
Measured rebuild times on real projects
Across real projects, edits rebuild 10× faster on macOS arm64, 24× faster on Linux aarch64, and 11× faster on Linux x86-64 than cargo build does on average. The per-project figures for a single-function edit followed by a build on Linux x86-64 are:
| Project | cargo build | cargo blaze build | Difference |
|---|---|---|---|
| ripgrep | 508 ms | 56 ms | 9.1× faster |
| nushell | 1.25 s | 236 ms | 5.3× faster |
| helix | 2.15 s | 116 ms | 19× faster |
| bun (1.25M lines of Rust) | 9.11 s | 451 ms | 20× faster |
Read as a workload rather than as four isolated rows, the pattern is that the wait an engineer pays per edit collapses from the multi-second range to a few hundred milliseconds or less on the projects measured, with the largest surveyed codebase, bun at 1.25M lines of Rust, sitting at the far end of that spread.
Side by side: which stage runs where
| Stage | cargo | blaze |
|---|---|---|
| First build of a project | Compiles the project | Runs cargo, then waits a few seconds to load the project |
| Build after one function changes | Links the program again from scratch | Compiles only the changed functions and writes them into the program already built |
| Edit delivered to a running program | Rebuild, then start the program again | Live edits reach a running program in About 20 ms |
| Command surface | cargo run, cargo test, cargo build | blaze run, blaze test, blaze build; other cargo commands pass straight through |
| Compiler used | The toolchain the project pins | Its own Rust, blaze-2026-10-25, no matter what the project pins |
| Platform coverage | macOS, Linux and Windows | macOS on Apple silicon and Linux |
| Final authority on correctness | cargo check and CI | Not the final word; differences should be reported |
Common misconceptions to correct before a pilot
- It is not a replacement build system. The first build belongs to cargo, and other cargo commands pass straight through to cargo.
- It is not bound to your pinned toolchain. blaze is its own toolchain, building every project with its own Rust, blaze-2026-10-25, which is today the nightly of that date; stable code and
#![feature(...)]code build. Your toolchain and CI stay the final word. - It is not free. It trades memory for speed: a few GB for a small project.
- It is not cross-platform today. On Windows every build remains cargo's.
- It is not battle-tested. The tool is young, so keep cargo check or your CI as the final word, and report anything that differs from cargo.
Demo: a Game of Life you can edit while it runs
The clearest way to feel the loop is to run one. Execute nix run github:indexable-inc/blaze to open a Game of Life window. On macOS on Apple silicon, its rules, colours and speed can be changed while it runs; elsewhere, the window runs without live edits. It needs Nix, and builds blaze from source the first time, so treat that first invocation as a warm-up rather than a measurement.
Rollout inside a team, and contributing back
Beyond local iteration, the project is working with a few teams on fast Rust CI and remote builds built on blaze. Teams it works with get early access and a direct say in what is built next, which is the practical reason to raise your hand early rather than waiting for a stable release.
For engineers who want to inspect or change the tool itself: how to build blaze from a checkout, run its tests, and send a change is documented in docs/contributing.md. To report a security problem, see SECURITY.md.
FAQ
Does blaze replace cargo in CI?
No. Your toolchain and CI stay the final word, and the standing recommendation is to keep cargo check or your CI as the last gate on any change.
What happens if part of my team is on Windows?
Nothing changes for them: on Windows every build remains cargo's, while the reported speed-ups apply to macOS arm64, Linux aarch64 and Linux x86-64.
Will nightly-only code stop building?
No. blaze builds every project with its own Rust, blaze-2026-10-25, which is today the nightly of that date, and both stable code and #![feature(...)] code build.
What does installation cost me?
A one-time download of about 100 to 135 MB, or reuse of rustup's toolchain; crates.io and Nix are alternative installation paths if those suit your environment better.
What does using it cost me every day?
Memory, in exchange for time: a few GB for a small project.
What is the benefit per edit?
Rebuilding returns in milliseconds once a function changes, and with live edits, saving a file reaches a running program in About 20 ms.
Action checklist for the next iteration cycle
- Install on a macOS on Apple silicon or Linux machine with the
curlone-liner, and leave Windows machines on cargo. - Run one first build and note the a few seconds of load time, so the team is not surprised that the first invocation behaves differently.
- Measure your own repository the same way the published numbers were produced: edit one function, then build, and compare cargo build with cargo blaze build against the reported baselines of 10× faster, 24× faster and 11× faster on their respective platforms.
- Budget a few GB of RAM per developer machine, and treat that as the explicit price of the speed.
- Keep cargo check and CI as the authority, and file anything that differs from cargo upstream rather than trusting a fast result on its own.
- If you want the faster path in CI itself, talk to the project: it is working with a few teams on fast Rust CI and remote builds, and those teams get early access and a direct say in what is built next.
Provenance, credits and license
blaze stands on the shoulders of giants. Thanks go to the people behind rust-analyzer, whose analysis and MIR blaze compiles from; Cranelift (Bytecode Alliance), the fast code generator; LLVM and inkwell, for the optimised tiers; salsa, the incremental engine underneath; object, for reading and writing executables; Rust and its compiler crates; and rustd (DioxusLabs), whose code blaze includes. None of these projects endorses blaze.
The tool shipped under an earlier name: blaze was called ra-jit until 2026-10-24, and cargo ra-jit still works. It was made at ix for den's native app under MIT or Apache-2.0.
For a delivery-focused team the decision is not whether millisecond rebuilds are attractive, but whether they can be adopted without weakening the guarantees CI already gives. This tool's design answers that on purpose: cargo and your pinned toolchain keep the authority, while the in-memory incremental path absorbs the edit-build-run loop that otherwise consumes most of an engineer's attention.