关于Bun用Rust重写的思考

背景

Bun 是一个基于 Zig 语言编写的 JavaScript/TypeScript 工具链（包含运行时、打包器、包管理器），由 Jarred Sumner 创建并于 2022 年发布。它因极快的启动速度和开发体验而迅速获得关注。然而，2024 年 9 月，Bun 的团队（背后公司 Oven）宣布将 Bun 的核心用 Rust 重写。这一决定在技术社区引发广泛讨论，尤其因为 Zig 社区与 Bun 有着深厚的历史渊源。本文作者是 Zig 语言的核心维护者之一（从语气和细节判断，很可能是 Zig 语言创始人 Andrew Kelley），他在 Hacker News 上以个人名义发表了这篇对 Bun Rust 重写的深度评论。

核心内容

历史回溯：从“初学者能量”到 VC 驱动

大约五年前，Jarred Sumner 加入了 Zig 社区。作者形容他拥有强烈的“初学者能量”——行动迅速、敢于尝试、一头扎进自己尚不擅长解决的问题里。虽然初期工程产出平庸，但通过这种方式他学到了大量知识，这是年轻人最有效的成长路径之一。

Jarred 将精力集中到 Bun 项目后，迅速吸引了全球 JavaScript 开发者的注意力。作为世界上使用最广泛的编程语言的配套工具链，Bun 的前景让无数人驻足。作者指出，这种关注本来可以通过多种方式变现——例如通过众筹轻松获得体面的生活（即使在旧金山标准下也是如此）。但 Jarred 是 Thiel Fellowship（泰尔奖学金）体系的产物，而非传统大学教育背景，这使得他从小就被灌输不加批判地接受硅谷思维，最终选择了风险投资。

与 Zig 的早期友好关系

最初，Jarred 对 Zig 项目表达了真诚的感谢。他在 Bun 官网上将性能成就归功于 Zig；他还为 Zig 软件基金会（ZSF）设立了每年 6 万美元的月度捐赠。作者认为，这些行为并非义务，但他做了，非常酷。即使在后来宣布 Rust 重写的博文中，Jarred 对 Zig 项目依然表达了作者认为是真诚的感激。

从这里开始变味：管理灾难

一旦 Bun 成为 VC 支持的初创公司，Jarred 就开始冲向终点线。不再是做一个自由开源的社区项目，而是经营一家企业。当 Jarred 突然变成经理时，他的“初学者能量”开始变得刺眼。作者写道，一个人为自己选择糟糕的工作生活平衡是一回事，要求别人也这样做完全是另一回事。Jarred 曾在内部说过：“Oven 会是一场苦战，尤其是头九个月。如果工作生活平衡意味着花大量时间不工作，那可能不适合你。”

作者通过内部消息渠道了解到：Oven 的面试者和员工之间有着活跃的葡萄藤，所有葡萄都传递着同一个信息——Jarred 是一个糟糕的经理：沟通差、期望不切实际、缺乏同理心、毫无管理经验。从雇佣角度看，这完全是一场闹剧。因此，虽然 Zig 社区的成员渴望找到能用 Zig 写代码的带薪工作，但大多数人才都避开了 Oven 和 Bun。

关系破裂：从合作到负担

Zig 和 Jarred 之间的裂痕逐渐扩大。Jarred 一心只关注生产力及初创公司的退出策略，这与作者对 Zig 项目的长期愿景越来越不一致。作者回忆，Jarred 不断催促他放下其他优先级，去实现语言服务器协议（LSP）和 VSCode 集成，而作者有更大的计划。

核心问题在于代码质量。 Zig 团队定期检查用户项目的代码。他们通过阅读源码来了解语言对用户的影响，测试变更对破坏性的影响，并检查性能退化。他们越发震惊地看到 Bun 代码库中的编程实践：在 Hack 之上叠 Hack、滥用断言、最严重的是——以极少的反思和消除 Bug/技术债务的时间，鲁莽地冲刺一个又一个功能。Jarred 早在拥有 LLM 辅助之前就已经在写“垃圾代码”。作者指出，Zig 团队本无职责去监督用户，但外界一直对 Zig 语言的安全性指指点点（因为 Zig 不像 Rust 那样有严格的内存安全保证）。Bun 不负责任的软件工程实践恰好证明了那些批评者的正确性，这让 Zig 团队很想与他们保持社交距离。

他们曾徒劳地试图引导 Bun 团队采用更好的编程实践。有少数英雄式的成员在一个不正常的公司里尽了最大努力，但无法阻止大势。到 RoboBun（AI 生成的贡献机器人）成为 Bun 的第一大贡献者之前，ZSF 就已经感觉 Bun 是一个净负债项目。公众会默认将 Bun 视为 Zig 编程语言的“门面”，但 Bun 实际上是“如何不写 Zig 代码”的最佳反例。同时，ZSF 预料到早晚有一天他们会变现（作者直言，他们那个含糊的“卖云服务”商业计划从一开始就是骗局），届时 Zig 会被连带负面报道，而且那份定期捐赠也会停止。

Anthropic 收购：Zig 的解脱

所以，当 Anthropic（AI 公司）最终收购 Bun 时，ZSF 松了一口气。捐赠果然悄悄停止了，但 ZSF 的账户早有准备。他们既不取消与 ZSF 的月度会议，也不露面——这并不令人意外。关系已然结束。

重写的迹象早已显现。收购后几天内，Zig 团队就怀疑 Rust 重写即将到来，而且他们对此乐见其成。收购一家大型 AI 公司带来的负担是：即使只是间接关联（Claude 用 Bun 运行，Bun 用 Zig 编写），也导致大量 AI 生成的劣质代码贡献涌入，以及一群品味低下的 AI 爱好者涌入 Zig 社区，他们需要被告知将 LLM 输出粘贴到论坛帖子中是反社交行为。作者一度担心 Zig 的身份会被大众称为“与 AI 相关的编程语言”。

当 Jarred 正式宣布 Rust 重写时，ZSF 欣喜若狂，甚至觉得好得难以置信。作者坦承，他原本不认为技术上能实现这种高难度迁移，但 Jarred 做到了。现在，作者可以像喝下一杯美味茶一样，杯子上写着“尝起来不再是我的问题了”。

对 Jarred 博文的逐点批评

作者对 Jarred 那篇宣布 Rust 重写的博文（该文文案非常精良，像是有万亿美元公司的营销部门在押注）提出了几个重要反驳：

1. 错误的二分法：博文制造了一个误导性选择——要么选“风格指南”，要么选“编程语言特性”来避免 Bug。作者指出，真正消除 Bug 的方式是投入工程资源。TigerBeetle（一个 Zig 项目）就是例子：他们真正花时间发现和消除 Bug，与 ZSF 保持健康关系，而 Bun 没有这样做。

2. 未经审查的百万行代码：博文称测试套件足够好，可以捕捉所有 Bug，因此可以直接推送百万行未审查的代码。作者质问：既然测试套件能保证正确性，那为什么你们在 Zig 代码里还有那么多恼人的 Bug？测试套件在 Zig 代码上不足以保证捕获 Bug，却足以覆盖百万行未审查的垃圾代码？

3. 性能提升的归因：博文将性能提升归功于 LTO（链接时优化）。但 Zig 从 Bun 诞生之日起就支持 LTO，甚至曾经默认启用（后来因遇到太多 LLVM Bug 而关闭，而这些 Bug 同样影响 Rust）。作者讽刺：“我们大概曾试图告诉你们启用 LTO，但你们没听。我们有好建议，见鬼！”

4. Fuzzing 的谎言：博文声称他们在对 Zig 代码进行 Fuzzing（模糊测试），但在之前的所有通话中，整个 Bun 团队都告诉 ZSF 他们没有做任何 Fuzzing。这简直是彻头彻尾的捏造。

5. 二进制大小优化：博文列举了一系列减少二进制大小的工程工作，以此论证“Bun 在 Rust 上更好”。但所有那些工程工作与重写毫无关系——它们本该在 Zig 版本中完成。作者认为，这正是博文花了这么长时间才发布的原因：他们一边做本应早就做的工程优化，一边把这当作 Rust 重写的功劳。

关键要点

• Bun 的 Rust 重写不是技术决裂，而是社区关系的终结：ZSF 长期以来