用Rust重写Bun

# 用 Rust 重写 Bun 来源：https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/ **用 Rust 重写 Bun (https://bun.com/blog/bun-in-rust)**（via (https://news.ycombinator.com/item?id=48837877)）Jarred Sumner 自 5 月 9 日起就一直在预告这篇博客文章，讲述他将 Bun 从 Zig 重写为 Rust 的经历，而重写本身所花的时间远比他预告的这段时间要长。 说实话，等待是值得的。这篇文章详细描述了一个极其复杂的代理工程，内容包括动态工作流、试运行、对抗性审查等各种有趣的技巧。 Jarred 在文章前半部分赞扬了 Zig 让 Bun 走到了今天。接着，他提出了一个核心观点，强调部分为我所加： > 我们的 bug 修复清单令人沮丧，我厌倦了每晚睡觉前还要担心 Bun 的崩溃问题。我并不怪 Zig——其他 Zig 用户并没有我们遇到的这些 bug，而且将垃圾回收与手动内存管理混合使用，对于软件来说是一种非常罕见的需求，以至于没有语言真正为此设计。如果没有 Zig，我们不可能走到今天，我将永远心存感激。**直到最近，对于像 Bun 这样的项目，编程语言的选择还是一种单向决策。** 所有人都知道，你不应该停下整个世界，从头重写一大块软件。Joel Spolsky 在 2000 年 4 月的《你永远不该做的事，第一篇》中强调了这一点。 而由当今前沿模型驱动的编程代理改变了这一局面。 为什么选择 Rust？归根结底还是内存管理方面的挑战： > 那批 bug 中有很大一部分是 use-after-free、double-free 以及错误路径中的“忘记释放”。在安全 Rust 中，这些都是编译器错误，并且有类似 RAII 的自动清理机制（通过 `Drop`）。 重写的一个关键促成因素是 Bun 的测试套件是用 TypeScript 编写的，这意味着它可以充当一致性测试套件。这使得代理框架能够自动化将 Bun 从 Zig 移植到 Rust 的大部分初始工作，最初只是作为一次实验，用来尝试我们如今称为 Mythos/Fable 的模型的早期版本。 > 起初，我并不指望它能成功。但几天后，测试套件中很大一部分开始通过，我看到新的 Rust 代码与原来的 Zig 代码库高度匹配。我的态度从“值得一试”变成了“我要合并它”。[…] 在那 11 天的大部分时间里（以及之后），我监控着工作流——手动阅读输出以检查问题和 bug，并提示 Claude 修改循环来修复问题。你要如何审查一个新增了超过 100 万行的 PR？你要如何建立足够的信心，以负责任地合并大量由 LLM 生成的代码？一个拥有百万断言的与语言无关的测试套件、对抗性代码审查，以及当出现问题时，修复生成代码的过程而不是手动修复代码本身。 Bun 的新实现已经在 Claude Code 中上线近一个月了： > Claude Code v2.1.181（于 6 月 17 日发布）及后续版本使用了 Bun 的 Rust 移植版。在 Linux 上启动速度提升了 10%，但除此之外几乎没人注意到。无聊是件好事。 在 Anthropic 工作的一个福利是你不用为 token 付费——当预估成本高达 165,000 美元时，这很方便！ > 合并前，这消耗了 59 亿未缓存输入 token、6.9 亿输出 token 以及 720 亿缓存输入 token 读取量——按 API 定价计算约为 165,000 美元。 整个事件是一个引人入胜的案例研究，展示了如何在协调的并行代理帮助下承担极其雄心勃勃的项目。