[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f89maltlamq03":3},{"code":4,"message":5,"data":6,"timestamp":35},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":31,"homepage":32,"updated_at":33,"history":34},"indexable-inc\u002Fblaze",16,"Incremental rust builds up to 92x faster than cargo\u002Frustc","Rust",293,12,55,5,[],"Keeps a Rust project type-checked and compiled in memory so edits are turned into machine code in milliseconds instead of rebuilds.","ra-jit is worth a look if you iterate quickly on a medium-to-large Rust project on supported hardware and upgrading to one exact Rust version is acceptable. It is not a drop-in replacement for cargo in general development.\n\n## The problem\n\nToday the loop is: change a function, run `cargo build` or `cargo run`, wait while rustc relinks objects, then navigate back to the state you were testing. Reaching a hot spot in a long-running program can take far longer than the edit itself. ra-jit changes the step after the edit: the first build remains cargo's, but once its background daemon has loaded and checked the workspace, the next `cargo ra-jit build` compiles only changed functions and writes them into the already-built program. The result is a finished build in milliseconds where cargo would relink.\n\n## What's different\n\nra-jit keeps the project parsed and type-checked in memory using rust-analyzer, the engine behind many Rust editor plugins, and generates machine code with Cranelift rather than invoking rustc for each rebuild. After an edit it patches only the changed functions into the binary cargo produced. The first build is cargo's; ra-jit's code is linked against what that build produced.\n\nThe live-coding crate `ra-jit-live` is the more interesting half: a program that adds a small poll to its main loop can accept new functions while running and keep its state, which matters for games, GUIs and anything slow to get back to a particular screen. The cost is architectural: the background daemon holds a few GB for a small project and tens of GB for the largest, and some edits still fall back to cargo. Plain `ra-jit enable` also makes your global `cargo build` go through ra-jit for every project; the project documents that this is slower than `cargo ra-jit` and can even be slower than plain cargo on some projects, so it is not a free convenience for editors and agents.\n\nThe README reports average speedups over incremental `cargo build` on ripgrep, nushell, helix and bun: 10× on macOS arm64, 24× on Linux aarch64 and 12× on Linux x86-64. Those are the author's benchmarks, not an independent measurement, and the full per-project numbers are worth reading before expecting the headline number on your codebase.\n\n## Who should try it\n\nGood fit: a developer on Apple-silicon macOS or Linux x86-64\u002FARM64 who spends the day editing a large Rust codebase with a steady toolchain, especially when they need to reach a specific runtime state repeatedly and are willing to add `ra-jit-live` to that program. Poor fit: Windows users, Intel Mac users, or anyone whose project must stay on stable Rust or moves across toolchain versions, because ra-jit works only with Rust 1.99.0 and rust-src, and every other version silently builds with plain cargo. Teams that need one shared toolchain in CI also gain little here, since the speedup applies to the local edit loop, not the build pipeline.\n\n## Requirements and limitations\n\nThe hard requirements are Rust 1.99.0 with the `rust-src` component, a supported platform, and enough RAM for the daemon. The project must also build with 1.99.0. Keep the four installed binaries together in `~\u002F.cargo\u002Fbin`. There are no prebuilt binaries yet, so `cargo install` or Nix compiles ra-jit from source and takes a few minutes; `cargo binstall` is only planned for the first binary release. After installation, the first build and the daemon's workspace load are still cargo-speed, so the benefit starts after a short wait, and only `cargo ra-jit status` tells you when it is ready.\n\nThe boundaries are the reason to read the compatibility page before committing. Some edits go to cargo by design, type errors fail as they would under cargo, and the borrow checker behaves as it does anywhere else. Installing through cargo and a manual `rust-toolchain.toml` with `channel = \"1.99.0\"` both avoid changing every project, so you can keep a global toolchain while opting one repository in. The project also recommends a file watcher such as watchexec for rebuild-on-save, because ra-jit has no watch mode of its own.\n\n## HotRepo's take\n\nHotRepo's first observation is 2026-10-25, when the repository showed 293 total stars at #16 on the NEW-REPOSITORY board for Rust, one day after tracking began; there is not yet enough comparable daily-board history to judge persistence. Treat that as a snapshot of early interest, not proof of momentum. Before adopting it, verify the per-project benchmark table and whether your project can be pinned to 1.99.0 with `rust-src`, because the version lock is the decision point that matters most.\n\n[Project source and documentation](https:\u002F\u002Fgithub.com\u002Findexable-inc\u002Fblaze)",{"slug":19,"name":20},"developer-tools","Developer Tools",[22,23,24,19,25,26,27,28,29,30],"cargo","compiler","cranelift","hot-reload","incremental-compilation","jit","live-coding","rust","rust-analyzer","Apache-2.0","https:\u002F\u002Fra-jit.ix.dev","2026-10-25T06:46:47Z",[],1792919617]