[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f14khcgreu06ik":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,[],"把 Rust 项目常驻内存做类型检查与编译，编辑后只把改动函数写成机器码，把重建缩到毫秒级。","如果你的日常是在中大型 Rust 项目里反复改一个函数再运行，并且能接受把工具链固定在某个具体版本，ra-jit 值得用一次。它不是 cargo 的通用替代品。\n\n## 解决什么问题\n\n现在的循环是：改一个函数，运行 `cargo build` 或 `cargo run`，等 rustc 重新链接，再想办法回到刚才测试的那个状态。对一个启动慢、需要一步步操作到某个界面的程序来说，回到原状态往往比改代码还费时间。ra-jit 改的是编辑之后那一步：第一次构建仍由 cargo 完成，等后台 daemon 把 workspace 加载并检查完，之后再执行 `cargo ra-jit build` 就只编译改动过的函数，并把它们写进 cargo 已经构建好的程序里。原本要重新链接的构建，现在几毫秒就结束。\n\n## 有什么不同\n\nra-jit 用 rust-analyzer（多数 Rust 编辑器插件背后的引擎）把项目持续解析、类型检查在内存里，用 Cranelift 直接生成机器码，而不是每次重建都调用 rustc。编辑后它只修补发生变化的函数，而不是从头链接，后者正是增量构建耗时的主要部分。第一次构建由 cargo 完成，ra-jit 的代码链接到 cargo 的产物上。\n\n更有意思的是 `ra-jit-live` 这个 crate：程序只要在主循环里加一个 poll，就能在运行中接收新的函数实现并保留状态，这对游戏、GUI 和任何需要反复回到特定界面的程序都很实用。代价也是结构性的：后台 daemon 对小项目就要占用几 GB 内存，对最大的项目可达几十 GB；而且并非所有编辑都走 ra-jit，部分改动仍会退回 cargo。用 `ra-jit enable` 让全局普通 `cargo build` 也走 ra-jit 时，项目文档明确说这比 `cargo ra-jit` 慢，在部分项目上甚至比普通 cargo 还慢，所以它不是给编辑器和 agent 白捡的便利。\n\n按 README 给出的作者自测数据，在 ripgrep、nushell、helix、bun 上相对增量 `cargo build` 的平均加速分别是 macOS arm64 10×、Linux aarch64 24×、Linux x86-64 12×。这是作者自己的基准，不是独立测量；在期待自己的代码库也达到标题数字之前，值得先看完整的逐项目数据。\n\n## 谁值得试\n\n适合：在 Apple 芯片 macOS 或 Linux x86-64\u002FARM64 上，用固定工具链长时间编辑大型 Rust 代码库的开发者，尤其是那种需要反复运行程序并走到某个特定状态的人，并且愿意给程序加上 `ra-jit-live`。不适合：Windows 用户、Intel Mac 用户，或者项目必须跟随 stable Rust、会频繁切工具链的团队，因为 ra-jit 只支持 Rust 1.99.0 和 rust-src，其他版本一律静默退回普通 cargo。CI 也难从中获益，因为加速的是本地编辑循环，而不是构建流水线。\n\n## 使用条件与边界\n\n硬性条件包括带 `rust-src` 组件的 Rust 1.99.0、受支持的平台，以及给 daemon 留够内存；项目本身也必须能用 1.99.0 构建。安装后的四个可执行文件需要放在同一目录（`~\u002F.cargo\u002Fbin`）里。目前还没有预编译二进制，所以用 crates.io 或 Nix 安装都要从源码编译，需要几分钟；`cargo binstall` 要等第一次二进制发布。装好之后，首次构建和 daemon 加载 workspace 仍按 cargo 的速度进行，收益要等一小段时间才出现，只有 `cargo ra-jit status` 会告诉你它是否就绪。\n\n这些边界决定了要不要在项目里长期用它。部分改动会按设计交给 cargo，类型错误会像在 cargo 下一样失败，借用检查器的行为和平时一致。安装方式上，用 cargo 安装配合 `rust-toolchain.toml` 里写 `channel = \"1.99.0\"`，可以只让一个仓库进入这套流程，而不是全局切换工具链。此外 ra-jit 本身没有 watch 模式，需要配合 watchexec 这类文件监视工具实现保存即重建。\n\n## HotRepo 点评\n\nHotRepo 最早的记录是 2026-10-25：仓库总计 293 stars，在 Rust 新项目榜排到 #16，距离开始追踪只有一天；可比较的每日榜单历史还不够，无法判断热度能否持续。这只是一个早期关注的快照，不是势头的证明。决定采用前，最该核对的是逐项目基准表，以及你的项目能否固定到 1.99.0 并装上 `rust-src`，因为版本锁定才是最关键的一道门槛。\n\n[项目源码与说明](https:\u002F\u002Fgithub.com\u002Findexable-inc\u002Fblaze)",{"slug":19,"name":20},"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",[],1792919701]