OpenSource Verdict: blaze Adds Millisecond Rust Rebuilds Alongside cargo — Install Paths, Benchmarks and Trade-offs

Evaluating a young open source build tool means separating three things: what it claims, what you can reproduce on your own machine, and what it quietly costs. For blaze, the OpenSource desk can put all three on the table at once. It is not a cargo replacement but a JIT layer that sits next to cargo, keeps compiled output resident in memory, and shortens the edit-to-build loop to milliseconds — with per-platform numbers published, an explicit memory price of a few GB for a small project, and a licence posture (MIT or Apache-2.0) that most adopters can clear without escalating to counsel.

Positioning: what blaze actually changes in the loop

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, rather than linking that program again from scratch. A program that opts in can take the new code while it keeps running, which is the difference between a "faster compile" and a shorter feedback loop. The engine identifies itself in the build output: the Finished line reports [ra-jit], the name the tool carried before its rename.

Command surface

• In any Rust project, blaze run behaves like cargo run, blaze test like cargo test, and blaze build like cargo build.
• Where cargo is installed, cargo blaze run is the same as blaze run, so existing aliases and scripts survive.
• Every other cargo command passes straight through to cargo.

Install: one curl line, three platform realities

Install with curl -fsSL https://raw.githubusercontent.com/indexable-inc/blaze/main/install.sh | sh.

On macOS on Apple silicon and on Linux it works 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 crates.io or Nix is preferred, other installation paths exist. The platform boundary is stated plainly — support covers macOS on Apple silicon and Linux, and on Windows every build remains cargo's.

First run versus steady state

The first build runs cargo, then waits a few seconds for blaze to load the project. That cold step is effectively the whole onboarding cost. After it, a function-level change returns a rebuild in milliseconds rather than in the seconds the baseline takes.

Benchmarks: one function edited, then build

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. With live edits, saving a file reaches a running program in About 20 ms. The per-project rows below are measured on Linux x86-64 for a single changed function:

Project	cargo build	cargo blaze build	Relative gain
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

Case read: what the four repos tell an evaluator

• The payoff is workload-dependent, not linear: ripgrep lands at 9.1× faster while helix lands at 19× faster, so your own crate mix decides the return.
• The largest sample, bun at 1.25M lines of Rust, is where the cargo baseline hurts most (9.11 s) and the in-memory engine pays back most (451 ms, 20× faster).
• Quotable limits: these rows describe one edited function on Linux x86-64 — not a clean build, not a dependency bump, and not a link-heavy release step.

What it costs to run

• Toolchain: 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 (2026-10-25), no matter what the project pins. Stable code and #![feature(...)] code both build, but your toolchain and CI stay the final word.
• Memory: it trades memory for speed — a few GB for a small project, which is a real constraint on shared or containerised dev boxes.
• Maturity: the tool is young, so keep cargo check or your CI as the final word, and report anything that differs from cargo.
• Portability: Windows developers see no change at all, since every build there remains cargo's.

Reproducibility check: the Game of Life window

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 — which makes the demo useful as a source-build smoke test before you trust a prebuilt installer.

Five misconceptions worth dropping before adoption

1. "It is a cargo rewrite." It is not; it runs beside cargo, and unimplemented commands pass straight through.
2. "My pinned toolchain decides what compiles." No — blaze builds with its own Rust snapshot regardless of project pins.
3. "Millisecond rebuilds everywhere." Live edits reaching a running program in About 20 ms is a macOS on Apple silicon capability; other platforms rebuild fast but do not hot-swap.
4. "CI is the natural first place to try it." The project's own guidance is to keep cargo check or your CI as the final word.
5. "Upstream projects stand behind it." None of these projects endorses blaze.

Provenance, licence and the dependency stack it inherits

blaze was called ra-jit until 2026-10-24; cargo ra-jit still works, so scripts written against the old name do not break on the rename. It was made at ix for den's native app under MIT or Apache-2.0.

The dependency graph is where a review should spend the most time, because the tool 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.

Community signals and the contribution path

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 — a small, design-partner stage rather than an open backlog. 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.

Action checklist for a two-week evaluation

1. Instrument the baseline first: time cargo build on one iteration-heavy crate, then rerun the same edit through cargo blaze build and compare against the 9.1× faster to 20× faster range the published rows show.
2. Confirm the platform you actually develop on; if part of the team is on Windows, that group keeps cargo's timings and should be measured separately.
3. Budget the RAM before rolling it out to shared machines, since a few GB per small project is the stated price of keeping the project compiled in memory.
4. Treat blaze-2026-10-25 as a second, nightly-pinned compiler in your risk register, and do not let it replace your toolchain or CI as the final word.
5. Reproduce the Game of Life window via Nix to verify a source build, and file anything that differs from cargo through the documented contribution and SECURITY.md paths.
6. Run the licence review against MIT or Apache-2.0 and map the upstream stack — rust-analyzer, Cranelift, LLVM, salsa, object, rustd — before shipping it into a product pipeline.

The OpenSource read: blaze is a narrow, honest tool. It publishes its platform gaps, names its memory cost, keeps cargo as the authority on correctness, and does not claim endorsement from the projects it builds on. Teams whose day is spent inside a Rust edit-compile loop on macOS on Apple silicon or Linux have a measurable reason to try it; everyone else is still waiting on cargo, and the project says so itself.