用Rust重写Bun

Jarred Sumner在博文中首先高度赞扬了Zig语言，认为没有Zig，Bun不可能走到今天。然而，随着项目发展，Bug列表越来越长——主要是内存管理错误（如use-after-free、double-free、错误路径下的忘记释放）。这些错误让Jarred“晚上睡不着觉”，担心Bun的崩溃问题。他坦言问题不在Zig，而在于Bun同时使用垃圾回收和手动内存管理，这种混合模式没有语言能完美支持。

选择Rust的核心原因是其安全内存管理：use-after-free、double-free等错误在安全Rust中会被编译器捕获，且RAII（资源获取即初始化）机制通过Drop实现自动清理。此外，Rust的所有权模型能从根源上消除一大类内存错误。

重写的关键前提是Bun的测试套件完全用TypeScript编写，并且语言无关。这意味着它可以充当一致性测试套件，自动验证新实现是否匹配原有行为。Jarred最初只是将此作为实验，使用早期版本的Fable模型（现为Mythos/Fable的一部分）尝试自动从Zig移植到Rust。出乎意料的是，几天内就有高比例的测试通过，新生成的Rust代码与原始Zig代码结构高度吻合。他的态度从“值得一试”转变为“我要合并这个”。

在11天中，Jarred主要通过监控工作流、手动检查输出、并提示Claude编辑循环来修复问题。整个重写消耗了5.9B未缓存输入token、690M输出token和72B缓存输入token，按API定价估算约16.5万美元（得益于Anthropic员工免token费）。最终生成了一个超过+100万行新增代码的Pull Request。

合并如此庞大的PR需要极端谨慎的策略：利用语言无关的测试套件（百万断言）进行自动验证，实施对抗性代码审查，并在出问题时优先修复生成代码的流程而非手工修补代码。这种思路确保了长期可持续性。

经济账上，16.5万美元的API费用看似高昂，但考虑到这是从零重写一个成熟的运行时，传统人力成本可能远高于此。收益方面，新Rust版本集成到Claude Code v2.1.181后，Linux上启动速度提升10%，但对用户而言几乎无感知——这正是设计目标：“无聊就是好”。

安全性是核心驱动力。Rust的安全保证将大量运行时错误转化为编译时错误，显著降低了生产环境崩溃的风险。不过，Jarred也承认，这一重写依赖于AI的“当前能力”，且预合并阶段的token消耗巨大，未来是否持续可行需进一步观察。

Joel Spolsky在2000年的经典文章《 Things You Should Never Do, Part I 》中警告永远不要重写大型软件。但Jarred的案例表明，当AI代理能够利用语言无关的测试套件、动态工作流、对抗性审查和流程修复机制时，这一旧规则可能被打破。

关键要素包括：独立于语言的高质量测试套件、充足的token预算、对AI输出进行系统性审查，以及“修复流程而非代码”的工程思维。这为其他面临类似重写困境的项目提供了可复用的方法论。

然而，当前的成功仍高度依赖特定条件：测试套件的完备性、模型能力（此处为Fable）、以及足够的经济投入。长期稳定性和代码可维护性仍有待时间检验。