Software Tool Watch: blaze Sits Beside cargo So Rust Rebuilds Finish in Milliseconds
Waiting on a linker is the part of a Rust working day that most often turns into a stray browser tab and a lost train of thought. The tool under review here, blaze, attacks precisely that gap: it works next to cargo rather than replacing it, holds the compiled project in memory, and after a save it recompiles only the changed functions and writes them into the program cargo already built. For anyone whose loop is edit, build, run, the published figures land a one-function rebuild in the millisecond range, with live edits reaching a running program in About 20 ms. The sections below cover setup, the command mapping, the measured numbers, platform limits and the checks worth running before this touches a shared machine.
What You Actually Type: The cargo-to-blaze Mapping
There is no new verb to memorise. Inside any Rust project, blaze run behaves like cargo run, blaze test like cargo test, and blaze build like cargo build. Every other cargo command passes straight through to cargo, and where cargo is installed, cargo blaze run is the same thing as blaze run.
Expect one slow start per project: the first build runs cargo, then waits a few seconds for blaze to load the project. After a function changes, rebuilding returns in milliseconds, and the Finished line reports [ra-jit], blaze's engine.
Step-by-Step: Installing and Trying blaze
- Install. Run
curl -fsSL https://raw.githubusercontent.com/indexable-inc/blaze/main/install.sh | sh. On macOS on Apple silicon and Linux, whether Rust is installed or not, blaze downloads the Rust it builds with once (about 100 to 135 MB) or uses rustup's toolchain. - Pick your channel. Other installation paths exist if crates.io or Nix is preferred; on a managed or locked-down machine, prefer a package channel you can audit over piping a fetched script into a shell.
- Warm up a project. Open an existing Rust project and run blaze build once. The cargo pass plus a few seconds of project loading happen here, so treat it as setup, not as your benchmark sample.
- Edit one function and rebuild. Run blaze build again. Millisecond-scale return and the [ra-jit] marker in the Finished line mean the incremental path took over.
- Try live editing. Launch with blaze run, then save a file. On supported platforms the change reaches the running program in About 20 ms.
- Verify before you trust it. Keep cargo check or your CI as the final word, and report anything that differs from cargo.
Benchmark Numbers: Edit One Function, Then Build (Linux x86-64)
| Project | cargo build | cargo blaze build |
|---|---|---|
| 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) |
Averaged across real projects rather than single samples, edits rebuild 10× faster on macOS arm64, 24× faster on Linux aarch64, and 11× faster on Linux x86-64 than cargo build does.
Why the Rebuild Returns So Quickly
blaze runs beside cargo and keeps the project compiled in memory. After an edit, it compiles only the changed functions and writes them into the program cargo already built, instead of linking that program again from scratch. A program that opts in can take the new code while it keeps running, which is what turns a rebuild into an update of something already on screen.
The speed has a price, and it is a resource trade, not a licence or privacy trade: it trades memory for speed, costing a few GB for a small project.
Compatibility, Toolchain Behaviour and Risk Checks
- Platforms. Support covers macOS on Apple silicon and Linux; on Windows every build remains cargo's.
- Toolchain divergence. blaze is its own toolchain. It builds every project with its own Rust, blaze-2026-10-25, which is today the nightly of that date, no matter what the project pins. Stable code and
#![feature(...)]code both build. - Authority stays outside the tool. Your toolchain and CI stay the final word; a fast local rebuild is not a correctness signal.
- Maturity. The tool is young, so treat cargo-blaze output differences as findings to report, not as noise.
- Footprint. Budget a few GB of memory for a small project before adding it to low-RAM laptops or shared CI runners.
- Install review. The default path pulls a script from the project's github repository at indexable-inc; teams with software-supply-chain rules should use crates.io, Nix or rustup-managed equivalents they can vet.
Demo: A Game of Life You Can Edit
Run 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.
Good Fit, or Not Yet: A Quick Read
| Situation | Verdict | Why |
|---|---|---|
| Iterating on one crate on Linux or a Mac with Apple silicon | Try it now | The reported per-edit gain (9.1× faster to 20× faster in the samples) lands exactly in the edit-rebuild loop |
| Live-tuning UI, simulation or game logic | Strong fit on macOS on Apple silicon | Saving a file reaches a running program in About 20 ms |
| Windows-only workstation | No gain yet | Every build remains cargo's |
| Strict pinned-toolchain or compliance-bound repos | Pilot outside CI first | blaze-2026-10-25 is used regardless of project pinning; your toolchain and CI stay the final word |
| Memory-constrained machines | Measure first | It trades memory for speed: a few GB for a small project |
Common Misconceptions
- "It replaces cargo." It runs beside cargo; the first build is still a cargo build, and other cargo commands pass straight through.
- "Fast build means correct build." cargo check and CI remain the authoritative result.
- "It honours my pinned toolchain." It does not: everything is built with blaze-2026-10-25, today's nightly for that date.
- "The old name is dead." The project was called ra-jit until 2026-10-24, and cargo ra-jit still works.
- "It works everywhere." On Windows, builds remain cargo's.
- "The demo proves live editing on any OS." Outside macOS on Apple silicon, the Game of Life window runs without live edits.
FAQ
Do I need Rust installed first?
No. On macOS on Apple silicon and Linux, whether Rust is installed or not, blaze downloads the Rust it builds with once (about 100 to 135 MB) or uses rustup's toolchain.
Why is the very first build slow?
Because it is cargo doing the full build, followed by a few seconds while blaze loads the project into memory.
How do I know the fast path engaged?
The Finished line reports [ra-jit], blaze's engine, instead of a normal full-build tail.
Can I keep using cargo commands?
Yes. Anything other than run, test and build passes straight through to cargo, and cargo blaze run is the same as blaze run wherever cargo is installed.
Is it used beyond individual laptops?
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.
How do I contribute or report a security problem?
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.
Data Cited in This Piece
- Per-edit build times on Linux x86-64: ripgrep 508 ms to 56 ms (9.1× faster); nushell 1.25 s to 236 ms (5.3× faster); helix 2.15 s to 116 ms (19× faster); bun, at 1.25M lines of Rust, 9.11 s to 451 ms (20× faster).
- Average gains by platform: 10× faster on macOS arm64, 24× faster on Linux aarch64, 11× faster on Linux x86-64.
- Live-edit latency: About 20 ms from saving a file to a running program.
- Install footprint: about 100 to 135 MB of bundled Rust, plus a few GB of memory for a small project.
- Internal toolchain identifier: blaze-2026-10-25; rename from ra-jit dated 2026-10-24.
Credits, History 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.
It was made at ix for den's native app under MIT or Apache-2.0, and was called ra-jit until 2026-10-24.
What to Do Next
Treat this as a workflow experiment rather than a migration: pick one crate you touch daily on macOS on Apple silicon or Linux, install through a channel your team can audit, run the first cargo-backed build, then time three single-function edits against cargo build for comparison. Keep cargo check or CI as the arbiter, watch the memory cost, and if you are on Windows or need strict toolchain pinning, wait for the gaps to close before planning around it.