← #802

Claude Code 现在跑在用 Rust 写的 Bun 上

文章摘要

Simon Willison 这篇短文验证了一个很多人关心的问题：Bun 那场备受争议的 Zig-to-Rust 重写，到底有没有真的上生产？

起因是 Bun 作者 Jarred Sumner 宣布，Claude Code v2.1.181（2026 年 6 月 17 日发布）及之后的版本，使用的已经是 Rust 版的 Bun，在 Linux 上启动速度快了 10%，而用户侧几乎没有其他可感知的变化。Sumner 的原话很克制：「Linux 上启动快了 10%，除此之外几乎没人注意到。无聊是好事。」

Simon 用命令行工具亲自查了 Claude Code 的二进制，找到两条证据。第一条是版本号：对 Claude 可执行文件跑 strings，能看到「Bun v1.4.0 (macOS arm64)」——而当时 GitHub 上 Bun 的最新公开发布还是 5 月 12 日的 v1.3.14，也就是说 Claude Code 里装的是一个尚未公开发布的 Bun 预览版。第二条是源码路径：grep Rust 文件名，得到 563 条源码文件路径，其中包括 bundler 和 runtime 组件的引用，比如 src/bundler/bundle_v2.rs。

Simon 的结论是：「看起来用 Rust 写的 Bun 确实正在数百万台不同设备上跑生产。」他把这件事读作一个信号——主流 JavaScript 工具链正在为性能转向 Rust，而这次重写成功地无声无息地铺到了数百万用户手上。

不过 HN 上 848 条评论展现的图景要复杂得多，也远不如作者本人那么淡定。争论大致分成四条主线：（1）Zig 是否本就不适合 Bun 这种大量小对象、生命周期互不相关的分配模式，还是团队工程能力不足；（2）Bun 现在有大量 unsafe Rust、且是逐行机械翻译，所谓「内存安全收益」是否名不副实；（3）为什么不干脆把 Claude Code 本身用 Rust 重写，而要绕道重写一个 JS 运行时；（4）项目治理和沟通方式——一个 100 万行以上的 PR 在不到一个月内合并，社区参与度接近于零，这对「开源项目 Bun」意味着什么。此外相当多用户报告 Claude Code 近期的 TUI 渲染问题、段错误和终端会话被搞乱的现象，虽然多数人都谨慎地表示无法确认与这次重写有关。

HN 评论精华

mrothroc（置顶之一）：钻进 Jarred 解释动机的原文后，他认为很清楚：在 Zig 下团队在手工做那些 Rust 里自动完成的事情。「人和 agent 有一个共同点：两者都是非确定性的。」Jarred 谈到在 Zig 里必须手工跟踪内存生命周期以便显式释放，结果就是一长串「有人漏了」的 bug；Rust 自动处理这件事，从他的 backlog 里移除了一整类错误——从工程管理角度看这是笔不错的交易。他还提出一个更一般的观点：编译器错误恰好是给编码 agent 套上的那种确定性护栏，「让它能编译」是个相当好的目标；确定性的测试把随机输出变成硬保证。zombot 反驳道：「让它能编译」只在它是运行时行为的良好预测指标时才成立——在 C++ 里我能让它编译，它照样会在运行时崩。
awesan：为 Zig 辩护——Zig（和 C）本来就不适合做大量小的、生命周期互不相关的分配。要写健壮的 Zig/C 代码，你必须自己管理生命周期，比如把分配归到 arena 上，或者用固定缓冲区装「东西」。「你完全可以这么做，那样 Zig 一点也不比 Rust 不健壮。但如果你想用『托管语言』式的分配模式（也就是 LLM 通常偏好的那种），用它就没道理了。」
Jarred（Bun 作者本人）：直接回应上条，给出了最有信息量的技术细节。分组分配和 arena 在 Zig 里确实好用，Bun 曾经一度几乎处处使用这个模式，但一旦掺进 GC 管理的内存、又想增量释放以降低 RSS，就变得很棘手；而且对会增长的数组用 arena 会大量浪费内存，因为它会保留每一个历史版本（mimalloc 的 arena 在这方面略好）。分组分配在 parser 和 AST 这类生命周期边界很清晰的地方尤其有效——「Rust 重写之后，我们在 Bun 的 parser 和 bundler 里仍然使用 arena，但其他地方就用得不多了。」
kllrnohj：对上面那句辩护给出最锋利的反驳——「如果你只要不写 bug，那所有语言都同样健壮，包括汇编。Zig 和 C 一样，就不是一门健壮的语言。我不明白为什么这会显得有争议？它显然本来就没打算做到健壮？」hresvelgr 说得更直白：「问题就在这儿——用 Zig 需要比 Bun 团队所具备的更严格的工程能力。」
cyber_kinetist：提供了一个常被忽略的技术原因——Bun 大量依赖 JavaScriptCore 这类现有 C++ 库，而它们要求的 RAII 和引用计数语义更接近 Rust 而非 Zig。你当然可以用 Zig 的惯用法（arena 分配、静态初始化）写一个 JS 引擎，但那意味着从头重写整个引擎。
BearOso：纠正了「Rust 自动做这件事」的说法——自动做这件事的是垃圾回收语言；Rust 仍然需要你思考和跟踪内存生命周期，只是借用检查器会抱怨、阻止你写错。「这也正是 LLM 喜欢 Rust 的原因：它对该修什么给出即时反馈。」Diggsey 进一步区分了两个被混淆的概念：lifetimes（防止 use-after-free 的静态分析）是不自动的，但对内存分配没有影响，纯粹是静态分析路径；ownership（所有权，决定何时分配和释放）才是自动的。nestorD 补了个冷知识：unsafe 并不让你关掉 Rust 的借用检查器。
feverzsj：「这是一次转译。而且还不是好的那种。生成的代码离惯用 Rust 差得远。有些人可能会认为这是个怪物。」daishi55 回应：可它看起来运行得挺好？而且这只是移植的开始，他们做的基本是机械的逐行移植，下一步是改成惯用 Rust——「我以为到现在人们该学会别赌这次重写会失败了。」cube00 给出更审慎的判断：和所有转译移植一样，真正的考验是它能否被长期扩展和维护；历史上跟转译输出打交道并不愉快，要重工到能安心扩展的程度需要大量返工。而且现有社区现在要么得学 Rust，要么得指望新的 Rust 开发者加入，而后者未必有足够投入去重构转译产物，毕竟他们可以去做 Boa 之类别的事。
brown9-2 问「如果项目达成了内存安全目标，惯用与否重要吗？」kikimora 直接否定前提：「不重要，但这个项目并没有达成内存安全目标。它是从上到下都在用 unsafe，带着同样的内存安全问题。」
weakfish（另一条置顶）：「也许是我在吃疯药，但我还是卡在『为什么一个 TUI 需要通过 JavaScript 跑在终端 React 上』这个问题上。Anthropic 觉得必须买下一个运行时才能让自己的 TUI 变好，这件事本身比任何东西都更说明工程质量。如果重写这么容易，为什么不用原生语言重写 Claude Code？那会便宜得多。」
switz 的辩护：「它基本能用，而且是个巨大的商业成功。这是经典的工程师对一个本质上是商业问题的东西追问『为什么用这个技术？』。他们早期选了它，它能用，它赚了离谱多的钱。故事结束。这不代表它是『最好』的选择或架构完美。」coldtea 的反驳很有力：这个反驳放在 2000 年或 2020 年的技术栈商业决策上都成立，但他们产品的全部卖点就是自动化地让「造任何东西又便宜又快」，从而消解这类商业顾虑——「他们不肯，或者更糟，做不到，这本身就是对那个说法的反证。」tripleee 补了个类比：「他们是在自己的技术选择之外获得成功的。他们的模型盖过了它，这是极其罕见的事，也不是能指望的事……这就像『你为什么全仓买 scamcoin 3.0 当投资策略？』——『我赚了五倍！故事结束！没问题！』」tacitusarc 给出本帖最形象的比喻：「这是『用锤子吃酸奶』式的论证。是，你当然能这么做。是，酸奶被吃掉了。只是……你看到有人用锤子吃酸奶，很难不好奇这是怎么回事。」
yojo：来自重度用户的负面体验，也是这条支线里最有分量的一条。「我整天都在 Claude 里工作。我痛恨他们满是 bug 的 UI。每个版本都是一批新 bug，老的有时会修，通常不会。任何回滚、复制文本、用他们的菜单系统——基本上除了敲字符之外的一切——都曾经或仍然有未处理的 bug。OpenAI 发布了有竞争力的模型，我现在转去 Codex 了，一个 bug 都还没撞到。如果你戴着 SOTA 王冠，人们会容忍你这堆 buggy 的烂摊子。王冠一滑，你这堆垃圾就变成巨大的负债。」
vmg12：给出了最扎实的性能分析。JS 应用的根本问题是极度单线程：你得到的是一个 100% 占用的线程，而功耗和发热随 CPU 占用非线性增长，单线程 JS 应用跑满一核就意味着 UI 会卡；Go 之类语言会把工作分到 8 个线程、各占 20%，总功耗更低。「Claude Code 如果做成 Electron 应用，性能上反而会更好，因为它可以把渲染卸载给浏览器和 GPU。」他还指出 OpenCode 的架构在这点上明显更好——Claude Code 把一切包括渲染都放在单线程 JS 里，OpenCode 有一个基于 Zig 的 TUI 渲染器承接这部分工作。不过他也为这类工具说了句公道话：它们经常被不公平地指责，因为它们会启动子进程而子进程往往很贵——如果你在用 rust-analyzer 配 Claude Code，绝大部分问题其实来自 rust-analyzer。
GuB-42：把「为什么不直接重写 Claude Code」这个问题问到底。tbrockman 给出了目前最完整的商业解释：孤立地看确实如此，但那会大幅削弱这次 Bun/oven.sh 收购的价值。Claude Code 不是 Bun 的唯一用户（在 Anthropic 内部可能都不是），这样他们能保住一个 JS 运行时和工具链——他们的编码模型有一天（如果还没有的话）在有选择时可能就偏好用它；而对这类应用，你猜怎么样，Anthropic 也有自己的云服务来托管和运行它们。「就算他们得到的只是一群选择 Bun 而非其他方案的开发者，那也给了他们直接重写 Claude Code 所得不到的话语权和席位。」59nadir 的看法更冷酷：这就是好营销，Bun 对更广的生态、尤其对 Anthropic 来说本来就不重要，「Bun 对 Anthropic 唯一的作用就是吸引注意力，所以他们就这么用了它」。
embedding-shape：从开源治理角度发难——「于是这个 FOSS 项目 Bun 在黑暗中静静死去，如今变成了完全不同的东西。我很高兴我的 TODO 里那条『调查 Bun 是否值得用』还没轮到。」并追问 Bun 的治理结构究竟是什么，「我猜今天本质上就是『Anthropic 决定什么被做、什么被接受』？」junon 反问「换成 Rust 为什么就杀死了项目？」stymaar 的回答被广泛认同：「Rust 这门语言和这场讨论无关，问题在于 bun 是被一个人 vibe coded 的，完全没有开源社区参与。『bun 这个开源项目』在那个时点基本就死了：别指望那些代码被强行用他们不喜欢的语言重写的 Zig 爱好者会继续跟着 Jarred。不过『bun 这个 JavaScript 运行时』没有死。」OJFord 补充了要点：重点在 FOSS 那部分——文中提到的 v1.4 还没有（或尚未）开源，Claude Code 本质上在用一个专有分支。pdp 提出一个有意思的观察：Bun 当初能成事，一个原因正是 Zig 吸引了一个小而极活跃的开发者社区，从 Zig 切到 Rust 实际上疏远了那个社区。foxes 则展示了现状：「作为开源、社区驱动的项目？你看过 GitHub 上那个仓库吗？里面有几千个来自 Claude agent 之类的 PR。是啊，真是个值得贡献的好地方，笑。」
gabrieledarrigo：把批评落在沟通上而非技术上。「我个人对整件事的看法相当负面，不管 Jarred 或 Simon 怎么说。Bun 被 Anthropic 拥有、以及整个用 AI 重写这件事都不是真正的重点（尽管挺有意思）。我的看法是 Jarred 和 Bun 没有展现出严肃、成年人的做法，从『这是我的分支，你们反应过度了』那条消息，到就这么把一个 100 万行以上的 PR 在不到一个月里合并。问题在沟通，而它被处理得极差，损害了信任、造成了分裂。采用 TypeScript 团队做 7.0 时那套做法就这么难吗？」pier25 说这正是他不再在新项目里用 Bun 的原因：「糟糕的项目治理。TS 7 是一个负责任、在乎用户的团队本该怎么做的好例子。」baq 则给出冷冰冰的现实主义：「我猜重点是这一切都不重要，Claude Code 用户没注意到，或者除了极小一撮人之外都不在乎。」snemvalts 回了四个字：「最低的门槛。」而 foldr 表达了另一种困惑：「除了我还有别人搞不懂围绕这件事的全部网络戏剧吗？重写在技术层面可能成功也可能不成功，我们等着看。Bun 项目没有立血誓永远用 Zig，换语言最终是他们的选择。除此之外，人们似乎情绪上极度投入，理由完全超出我的理解。」
lionkor：给出一个很好的元解释，说明为什么这个话题必然爆炸。重写几乎总是糟糕的决定，最好情况是不知情者的天真决定，最坏情况会杀死产品（这里有谁在用 Netscape？）。所以人们从一开始就会对「我们用 Rust 重写了 xyz」持怀疑态度。但这件事还额外堆满了「tech bro」元素：用 Rust 重写、用 AI 重写、用 JS 写终端应用、还牵扯上 Zig（很多人心爱的语言）。「这会吸引每一个抱持怀疑的开发者。唯一缺的大概是区块链，如果它还酷的话。它精准命中了所有『什么？为什么？』的点。」
Philip-J-Fry：为段错误报告给出最合理的技术解释——Zig 版本本来就有段错误；纯粹因为这是从 Zig 到 unsafe Rust 的逐行翻译，所有导致段错误的 Zig 代码在 Rust 版里同样会导致段错误。要等到他们把它重构成惯用且内存安全的 Rust，这些问题才会被修掉。vips7L 一句追问：「可如果段错误是新出现的，那就意味着它来自 LLM 咯？」
root_axis：来自生产环境的数据点——「这和我用 Bun 的整体体验一致。作为一个想法，它遥遥领先地是最好的 JS 运行时，但在稳定性上很糟，段错误频率是 node 的 20 倍（这个数字基于 newrelic 遥测）。」nicce 补了一句杀伤力很强的对照：「在 Chrome 或 Firefox 里，一次段错误通常自动等于一个 CVE，多数情况下还有数千美元赏金……」
aureate：一个尖锐的数字对照——被移植的 Bun 有 5000 多个 open issue，它被用在有 11000 多个 open issue 的 Claude Code 里。zahlman 出来平衡：CPython 也有 5000 多个 open issue，但仍被普遍视为相当可靠。aureate 的回应很有说服力：CPython 约 7000 open 对约 70000 closed，比例是 1:10；Bun 高于 1:2.5，Claude Code 略高于 1:6。更重要的是，Bun 最老的 issue 来自 2021 年 9 月，Claude Code 是 2025 年 2 月，而 CPython 最老的来自 2000 年 6 月——Claude Code 的 issue 总数（open + closed）已经和 CPython 差不多都在 7.7 万左右，但它只用了一年半，CPython 花了 26 年。「这是个好对照，因为无法用流行度解释：以 Claude Code 的真实用量来说，它离 CPython 还差得远，即使只算这一年半。」
luciana1u：一句概括整件事的黑色幽默——「一个终端应用的供应链现在长到包含一次运行时收购。在『我们用 Rust 重写了它』和『发布吧』之间的某处，有人说了句『或者我们干脆把这家公司买下来』。」
overgard：叠满所有担忧的一句吐槽——「太好了，那个会未经许可随手访问我 home 目录的 vibe coded prompt injection 载体，现在跑在一个大量使用 unsafe Rust 的 vibe coded 预发布运行时上。能出什么问题呢？」
rekttrader：把动机指向经济结构——「他们只是极其成功的糟糕工程师，善于描述问题，且有无限的 token 预算。如果他们自己付 token 费用，软件会更好；他们只是没有财务动机去追求性能。」他还捎带爆了个料：「AI 数据中心的一个脏秘密是，它们的 GPU 集群只跑出 40-60% 的效率，而因为钞票机器嗡嗡响，他们就直接再买更多。你想知道他们为什么这么怕中国的竞争吗……他们没法像现在这样浪费。」
bel8：一条难得的乐观——「与很多人相反，我很期待 Jarred 和团队会把移植后的代码打磨好，它会作为开源项目继续繁荣。」