我对Bun使用Rust重写的一些看法

原文链接：https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html

历史回顾

大约5年前，Jarred刚加入Zig社区时，我形容他具有强烈的“新手能量”。也就是说，他行动迅速，尝试各种不同的事物，一头扎进自己尚未准备好解决的问题中，从工程角度来看结果平平，但在这个过程中学到了很多东西。我认为这是一种非常健康的态度，尤其对年轻人和学生来说。这是提升自己、学习新东西的最佳方式。

当他把精力集中在Bun上时，开始引起关注。JavaScript作为世界上最流行的编程语言，一个充满前景的新工具链自然能吸引大量目光。

这些关注本可以有几种不同的利用方式。例如，他本可以通过众筹轻松获得体面的生活，即使按旧金山的标准也是如此。但他毕业于蒂尔奖学金流派而非大学，本质上从小就接受了不加批判地拥抱硅谷思维模式的熏陶，于是他接受了风险投资。

从一开始，Jarred对Zig项目就很感激。他在Bun网站上把项目的性能成就归功于Zig。他还为Zig软件基金会设立了每月捐赠，每年总计6万美元。他本不必做这些事，但他做了，这相当不错。即使在他那篇博文中，他也表达了对Zig项目真诚的感激之情。

然而，一旦Bun成为风投支持的初创公司，他就开始向终点冲刺。此时，Jarred不再是在一个自由开源项目上工作，与社区共同学习和成长，而是在经营一家企业。就在这一刻——当他突然成为一名管理者时——这种“新手能量”对我来说开始有了不同的意味。一个人为自己选择糟糕的工作与生活平衡是一回事；要求别人也这样做则完全是另一回事：

“Oven将是一段艰难的历程，尤其是最初九个月左右。如果工作与生活的平衡意味着大量时间不工作，那可能不太合适。”

有趣的是：人们会互相交流。

我和那些去Oven面试过的人谈过，也和在那里工作过的人谈过。这些人彼此交流。每个人都在互相沟通。小道消息网络庞大而健康，挂满了多汁的葡萄，而这些葡萄里都包含着同样的信息：Jarred是个糟糕的管理者。沟通不畅、期望不切实际、缺乏同理心、毫无经验。从就业角度来看，完全是一场灾难。

因此，尽管Zig社区成员渴望找到有偿编写Zig代码的工作，但大多数人才都对Oven和Bun敬而远之。

与此同时，Zig和Jarred之间的裂痕开始扩大。他过分专注于生产力和初创公司的退出策略，这与我为Zig项目规划的长期愿景越来越不一致。我记得他一直催促我放下其他所有优先事项，去实现语言服务器协议和VSCode集成，而我当时有更大的计划。

然而，主要问题是代码质量。

Zig团队定期检查我们用户的项目。我们阅读源代码以了解语言如何影响用户，测试更改以评估破坏性可能带来的问题，并检查性能退化情况。

我们对Bun代码库中的编程实践越来越感到震惊。一个接一个的hack。滥用断言。最糟糕的是，肆无忌惮地快速推出一个又一个功能，很少花时间反思和消除bug及技术债务。早在Jarred能用上大语言模型之前，他写的代码就已经很“潦草”了。当然，我们无权干涉用户的行为，但你可能已经注意到人们不断对着我们大喊内存安全问题。你可以想象，我们可能想与这样一个项目保持社交距离，因为它不负责任的软件工程实践恰好招致了人们急于提出的那种批评。

我们曾徒劳地试图引导他们采用更好的编程实践。在这个功能失调的公司里，有几位杰出的英雄尽了最大努力。你们知道自己是谁。但你们无法阻挡潮水。

到了这个时候，ZSF的我们都觉得Bun是一个净负担，而这还是在RoboBun成为第一贡献者之前。一方面，公开被当作Zig语言典范的项目实际上却是“如何不写Zig代码”的首要例证，这让人感到不适；另一方面，他们迟早会卖掉公司（说实话，他们那个模糊的“卖某个云产品”的商业计划从一开始就是个笑话），我们会因此受到负面牵连，而且会失去那笔定期捐赠。

所以，当Anthropic的收购最终发生时，我们ZSF的人都松了一口气。当捐赠悄无声息地停止时，我们的银行账户已有准备。当他们既没有取消与我们的月度会议，也没有出现时，我们并不惊讶。关系结束了。

（重）写的迹象显而易见。甚至在几天之内，我们就已经怀疑会有Rust重写。我们对此表示支持！被一家大型AI公司收购是一个负担，因为即使是“Claude由Bun编写，Bun由Zig编写”这种间接关联，也不仅带来了大量随意的低质量贡献，还导致大批缺乏品味的AI爱好者涌入Zig社区，不得不告知他们在论坛帖子中粘贴大语言模型输出是不礼貌的。有那么一刻，我担心Zig的身份会被人通俗地认为是一种与AI相关的编程语言。

当Jarred宣布Rust重写时，我们欣喜若狂。这好得令人难以置信。我得承认，我原以为技术层面还不足以完成这一壮举。但他做到了，现在我正比喻性地从一个写着“尝起来像不再是我的问题了”的杯子里啜饮美味的茶。

回应那篇博文

那篇博文写得很专业。几乎就像一家万亿美元公司的市场部在这篇文章上押了很多钱一样。

不过，我确实有一些异议。

博文中呈现了一种二分法，好像你要么得选择“风格指南”，要么得选择编程语言特性来避免错误。这种花招把读者的注意力从消除错误的主要方法上移开了：那就是投入工程资源。你远远没有给TigerBeetle足够的赞誉。很简单，他们花时间发现并消除了错误，他们努力与ZSF保持健康的关系，而Bun这两件事都没做。

所谓“提交所有百万行未经审查的代码”的理由是测试套件足够好，可以捕捉所有问题。那么你为什么说Zig代码中有那么多恼人的错误呢？测试套件足以捕捉所有问题的情况哪里去了？它不足以捕捉Zig代码中的错误，却足以捕捉一百万行未经审查的潦草代码中的错误？

性能提升被归因于LTO，而Zig在Bun存在的整个过程中都支持LTO。它曾经是默认启用的，直到我们遇到太多LLVM错误，所有这些错误也影响Rust。我们可能曾试图告诉你尝试启用它，而你没有听。我们有好的建议，该死的！

博文暗示你们在勤勉地fuzzing Zig代码，而在我们的通话中，Bun团队告诉我们他们没有fuzzing任何东西。

博文概述了大量为减小二进制大小所做的工程工作，以更好地论证“Bun在Rust中更好”。但所有这些工程工作都与重写无关。我认为这（特别是博文中“二进制大小”部分）正是博文花了这么长时间才发布的原因——你们在做那些从一开始就应该在Zig代码库中完成的工程工作。多年来我们一直在警告你们滥用comptime。我们甚至专门为那些需要审计comptime/内联使用和编译时间项目制作了这个时间报告工具。

我注意到你忽略了提及编译速度。Zig编译器项目大约有60万行代码——与重写前的Bun规模大致相同——我从头开始干净缓存构建需要16秒，然后启用增量编译后每次编辑只需90毫秒。重写后的Bun对应的测量数据是多少？

我们今天学到了什么？

这里的主要问题是关系破裂，正如我上面概述的，这与编程语言特性无关。当然，我不指望那篇博文会承认这一点。确实，这一手玩得很好。

放大一点看，我想澄清几件事。

第一，我真心感谢Bun给予ZSF的捐赠。我们把那些钱用来支付贡献者为Zig工作。

第二，我实际上对Jarred没有任何个人批评。他的品味与我不同，他对生活的追求也与我不同。但我认为他在他现在的位置上实际上很快乐和成功。他找到了如何实现他生活中想要的所有东西的方法。他可以沉浸在自己的生产力狂想梦中，他可能已经非常富有了。他拥有小型科技名人的地位。

说实话，我认为他为自己做得很好，我不希望他有什么不好。

我在这篇博文的更新中加了这一段，因为似乎人们很难相信我说这不是针对个人的，而且我实际上接受Jarred本来的样子，并且确实认为按照他自己的标准他是成功的，而且我真的为他感到高兴。但这是事实。我接受与我截然不同的人。我不会因为别人与我品味不同而记恨他们。我甚至不憎恨我在商业世界中的对手。如果说我们有什么共同点的话，那就是我们都在玩同一个游戏，尽管在不同的队伍。但我们都热爱这个游戏。

话虽如此，我很高兴我们的商业利益不再纠缠在一起！一旦互联网不再公开争论这次重写对Bun来说是好是坏（基于语言选择），我相信我们的互动就到此为止了。
¯\_(ツ)_/¯
感谢阅读我的博文。

---

翻译说明： 本文是Andrew Kelley（Zig语言创始人）于2026年7月9日发表的博文，就Bun项目从Zig重写为Rust一事发表看法。文中回顾了与Bun创始人Jarred的交往历史、Bun项目代码质量问题、以及最终被Anthropic收购后的Rust重写。作者认为核心问题是关系破裂而非编程语言特性，并对Bun团队的一些工程实践和博文中的论点提出了批评。翻译力求保持原文的语气和风格，包括一些口语化和带有情绪的表达。