用 Rust 重写 Bun

Jarred Sumner 从 5 月 9 日起就一直在承诺这篇关于将 Bun 从 Zig 重写为 Rust 的博文，而等待的时间远比他完成重写本身要长。说实话，值得等待。这是一篇对极其复杂的 agentic engineering（智能体工程）的详细描述，涉及动态工作流、试运行、对抗性审查以及其他各种有趣的技巧。

Jarred 在博文前半部分大力赞扬 Zig 让 Bun 走到了今天这一步。然后我们看到了文章的一个核心观点，强调部分为我所加：

我们的 bug 修复列表让人感觉糟糕，我厌倦了每晚担心 Bun 崩溃而入睡。我不怪 Zig——其他 Zig 用户没有我们遇到的这些 bug，而且将 GC 与手动管理的内存混合使用，是软件中相当罕见的需求，没有语言真正为此设计。如果没有 Zig，我们不可能走到今天，我将永远心存感激。

直到最近，对于像 Bun 这样的项目，编程语言的选择还是一次性的决策。所有人都知道，你不应该停下来从头重写一个大型软件。Joel Spolsky 早在 2000 年 4 月的《你永远不该做的事，第一部分》中就强调了这一点！但由当今前沿模型驱动的编码智能体改变了这一局面。

为什么选择 Rust？ 一切都归结为内存管理方面的挑战：

那个列表中的很大一部分 bug 是 use-after-free、double-free 以及错误路径中的"忘记释放"。在安全的 Rust 中，这些是编译器错误，并且有类似 RAII 的自动清理机制（通过 Drop）。

重写的一个关键促成因素是，Bun 的测试套件是用 TypeScript 编写的，这意味着它可以充当一致性测试套件（conformance suite）。这使得智能体工具能够自动化完成从 Bun 到 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 美元。

整个事件是一个引人入胜的案例研究，展示了如何在协调的并行智能体帮助下，承担雄心勃勃的项目。

来源：Hacker News

标签：ai, rust, zig, generative-ai, llms, ai-assisted-programming, anthropic, bun, conformance-suites, agentic-engineering, claude-mythos-fable