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

我对 Bun Rust 重写项目的看法

背景：用 Rust 重写 Bun

历史沿革

大约五年前，当 Jarred 加入 Zig 社区时，我曾这样形容他： “他身上有一种强烈的‘初学者精神’。”也就是说，他行动迅速，尝试了各种各样的新事物，一头扎进那些自己尚未具备足够能力去解决的问题中，虽然在工程层面的结果平平，但在这个过程中却学到了很多、收获颇丰。在我看来，这种态度非常健康——尤其是对于年轻人和学生而言。这正是提升自我、不断学习新知识的最佳方式。

随着 Jarred 将精力全部投入 Bun 项目，他的影响力逐渐显现出来。作为全球最受欢迎的编程语言之一——JavaScript， 一个充满潜力的新工具链，自然会吸引无数目光的关注。

其实，这种关注本可以以多种方式加以利用。 例如，他完全有可能通过众筹轻松谋生，即便按照旧金山的标准来看也是如此。 然而，由于 Jarred 毕业于泰尔奖学金项目，而非传统大学教育体系，他从小就被灌输了一种近乎盲目地拥抱硅谷思维模式的态度， 并且最终选择了风险投资。

从一开始，Jarred 就对 Zig 项目心怀感激。他在 Bun 的官方网站上，将 Zig 在项目性能方面取得的成就归功于它。他还向 Zig 软件基金会 每月捐赠了 6 万美元。其实，他本不必做这两件事，但他还是做了——而且这对他来说已经相当了不起。 甚至在他那篇我所引用的博客文章中，他也表达了自己对 Zig 项目由衷的敬意与感激之情。

然而，当 Bun 成为一家获得风投支持的初创公司后，Jarred 开始加速冲刺，朝着终点线奋力奔跑。此时，他不再专注于一个免费开源的项目， 也不再与社区共同学习、共同成长，而是开始经营一家企业。 就在这一时刻——当他突然成为一位管理者时——这种“初学者精神”对我来说有了截然不同的感受。 选择一种糟糕的工作与生活平衡，固然是一回事； 而要求他人也这样做，则完全是另一回事：

“Oven 的工作节奏会非常紧张，尤其是在最初的九个月左右。如果工作与生活的平衡意味着要花大量时间不工作，那么这大概并不适合你。”

有趣的是：人们彼此之间总是在交流。

我和那些在 Oven 面试过的人聊过。我也和在那里工作的员工谈过。 他们彼此交谈，大家互相沟通。信息传播渠道庞大而健康，其中充满了丰富的信息——而这些信息的核心都指向同一个结论： Jarred 是一个“臭名昭著”的管理者。沟通不畅、期望过高、同理心不足、缺乏经验……从就业的角度来看， 这简直是一场彻头彻尾的失败。

因此，尽管 Zig 社区的成员们都渴望在钟表上用 Zig 进行编码工作，但大多数人才却纷纷避开了 Oven 和 Bun。

与此同时，Zig 与 Jarred 之间的裂痕也在不断加深。他对生产力的单一化追求，以及他对创业公司退出策略的考量， 与我对于 Zig 项目更长远的愿景日益背道而驰。我记得他曾反复催促我放下其他所有优先事项， 专心致力于语言服务器协议的实现以及 VSCode 的集成，而那时我的计划远比他宏大得多。

然而，真正的问题在于代码质量。

Zig 团队会定期检查用户项目的进展。我们阅读源代码，以了解该语言如何影响用户；我们测试各项更改，看看可能引发的故障问题；我们还会仔细排查性能回归。

我们对 Bun 代码库中看到的编程实践感到愈发震惊。层层堆叠的技巧，层出不穷的“小修小补”。滥用断言。 更重要的是，他们不顾一切地快速推进功能，却几乎没有花时间进行反思，也没有及时修复漏洞或消除技术债务。早在 Jarred 能够使用大语言模型之前，他就已经开始写出一些低质量的代码。如今，我们无权去监管用户的行为，但你或许已经注意到，有人总是对着我们大声抱怨内存安全问题。可想而知，我们多么希望与这样一个项目保持一定的距离——因为其不负责任的软件工程实践，恰恰招致了人们最迫切想要抨击的批评之声。

我们曾徒劳地试图引导他们转向更好的编程习惯。在这家运转失灵的公司里，确实有一些杰出的英雄竭尽全力。你知道自己是谁。但你无法阻挡潮水的上涨。

到这个时候，我们在 ZSF 已经觉得 Bun 实际上是一种净负债——而这还早于 RoboBun 成为排名第一的贡献者。伴随着一种不适感：原本被公认为 Zig 编程语言“最佳代表”的人，竟成了“如何写 Zig 代码”的典型例子；在某个时刻，他们最终选择了出卖自己（坦白说，他们那模糊的“卖点云服务”商业计划从一开始就注定是闹剧）， 我们也因此间接承受了一些负面舆论的影响，最终再也无法收到那笔稳定的捐款。

所以，当 Anthropic 最终完成收购时，ZSF 的大家松了一口气。当捐款悄然停止时，我们的银行账户早已做好了迎接它的准备。 当他们既没有取消与我们的每月会议，也没有出现时，我们毫不意外。 这段关系，就此结束了。

重写之路已近在眼前。甚至在短短几天之内，我们就已经隐约察觉到，Bun 可能会迎来一次 Rust 重写。而我们当时正满怀期待！大型 AI 公司的收购，无疑带来了一重负担——因为即使 Claude 的代码部分是以 Bun 编写的，而 Zig 的代码又以 Rust 编写的，这不仅引发了大量 低质量贡献的激增,还让一批品味低俗的 AI 爱好者涌入 Zig 社区。这些人不得不被告知：把 LLM 的输出粘贴到论坛帖子中，实在是不道德的行为。 那一刻，我甚至担心，Zig 的身份可能会被大众戏称为一款与 AI 相关的编程语言。

当 Jarred 宣布要进行 Rust 重写时，我们欣喜若狂。这听起来好得令人难以置信。 说实话，我一度以为，这项技术根本不足以完成这样的壮举。 然而，他做到了——而如今，我仿佛在用一杯写着“这味道，已经不再是我的问题了”的茶， 细细品味着那美妙的滋味。

回应这篇博客文章

这篇博客文章写得十分出色。几乎就像一家万亿级公司的市场部，正把大量的资金押注在这篇文章上。

不过，我还是有一些想法想提出来。

文中呈现了一种二元对立：要么选择“风格指南”，要么选择某种编程语言特性来避免错误。 这种巧妙的转述，反而让读者将注意力从主要的错误消除方式上转移开——即通过将工程资源倾注于此。 我们并没有真正给予 TigerBeetle 应有的认可。简单来说，他们花了大量时间去发现并修复漏洞，努力与 ZSF 建立健康的关系，而 Bun 却没有做到这一点。

关于“将所有百万行未经过审查的代码都提交出去”的论点，有人认为测试套件已经足够强大， 足以覆盖所有问题。那么，为什么你还要说 Zig 代码中存在如此多令人恼火的错误？测试套件为何不能完全覆盖所有问题？ 在 Zig 代码中，测试套件的确不足以完全捕获所有错误，但在一百万行未经审查的低质量代码中， 它却足以应对大部分问题吗？

性能提升归功于 LTO，而 Zig 在 Bun 的整个生命周期中一直支持 LTO。起初，LTO 是默认开启的，直到我们遇到了太多 LLVM 错误——而这些错误同样会影响 Rust。

我们或许本该提醒你尝试开启 LTO，可你却始终没有听从。真是有备而来啊！

文章声称，他们在对 Zig 代码进行“模糊测试”。然而，在我们与 Bun 团队的多次沟通中，他们却表示自己根本没有进行任何模糊测试。 这显然是一种彻头彻尾的捏造。

这篇博客文章列举了许多工程优化措施，旨在减小二进制文件的大小，从而更好地证明“Bun 在 Rust 中表现更佳”。然而，这些工程优化工作与重写项目毫无关联。 我想，这也正是为什么这篇博客文章迟迟未能发表的原因：你本该从一开始就着手进行那些本应在 Zig 代码库中完成的工程工作。多年来，我们一直在提醒你注意你的 comptime 滥用问题。我们甚至专门针对那些需要审计 comptime/inline 使用情况以及编译时间的项目，推出了时间报告工具。

我注意到，你竟然忽略了编译速度这一关键指标。 Zig 编译器的代码量约为 60 万行——与重写前的 Bun 大致相当。我使用干净的缓存，从零开始构建，耗时 16 秒；随后，每次进行增量编译，只需 90 毫秒。那么，重写后的 Bun 又有哪些相应的性能数据呢？

今天，我们学到了什么？

从更宏观的角度来看，我想澄清几点。

首先，我真心感谢 ZSF 从 Bun 获得的捐款。我们用这笔钱支付了贡献者的报酬， 让他们继续为 Zig 付出努力。

其次，我其实并没有对 Jarred 有任何个人的不满。他的品味与我不同，他对生活的追求也与我有所差异。 但我认为，他此刻的境遇，恰恰是他所追求的幸福与成功所在。 他已经找到了实现人生目标的方式，实现了自己心中对生产力的无限憧憬——他很可能早已富甲一方， 甚至拥有了些许科技界的名人地位。

老实说，我认为他为自己做得很好，我也不会对他心怀恶意。

话虽如此，我很高兴我们的商业利益已经不再交织在一起！ 一旦互联网上不再就重写对 Bun 来说究竟“好”还是“坏”这一话题展开公开争论，我相信我们的互动也就此告一段落。

¯(ツ)/¯