我对Bun用Rust重写的看法

# 我对 Bun 用 Rust 重写的看法 来源：https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html 背景：将 Bun 用 Rust 重写（https://bun.com/blog/bun-in-rust） ## 历史 大约五年前，当 Jarred 加入 Zig 社区时，我形容他带有强烈的“初学者能量”。也就是说，他行动迅速，尝试了很多不同的事情，一头扎进他尚未具备解决能力的问题中，导致工程结果平平，但在这个过程中学到了极多。我认为这是一种非常健康的态度，尤其对年轻人和学生而言。这是提升自我、学习新事物的最佳方式。 当他把精力集中在 Bun 上时，他开始吸引关注。JavaScript 是世界上最流行的编程语言，一个前途光明的新工具链自然会吸引大量潜在目光。 这些注意力本来可以有几种不同的利用方式。例如，即使是按照旧金山的标准，他也能很容易地通过众筹获得体面的生活。但因为他接受的是蒂尔奖学金（Thiel Fellowship）的思想体系，而非大学教育，他从年轻时就被塑造为不加批判地拥抱硅谷思维，于是他接受了风险投资。 从一开始，Jarred 就对 Zig 项目心存感激。他在 Bun 的网站上将项目的性能成就归功于 Zig。他设立了对 Zig 软件基金会（https://ziglang.org/zsf/）的月度捐赠，每年总额达 6 万美元。他本不必做这两件事中的任何一件，但他做了，这非常酷。即使在我要引用的那篇博文（https://bun.com/blog/bun-in-rust）中，他也表达了对 Zig 项目我视为真诚的感谢。 然而，一旦 Bun 变成了风投支持的初创公司，他就开始冲向终点线。现在，Jarred 不再是参与一个自由开源项目、与社区一起学习和成长，而是在经营一家企业。正是在这个时刻——当他突然成为一名管理者时——这种“初学者能量”对我而言有了不同的滋味。一个人为自己选择糟糕的工作生活平衡（https://nitter.net/jarredsumner/status/1544821137128927232）是一回事；要求他人也这样做（https://web.archive.org/web/20220824093845/https://twitter.com/oven_sh/status/1562248121656102914）则完全是另一回事： > “Oven 将会是一个艰苦的奋斗期，尤其是最初的九个月左右。如果工作生活平衡意味着花大量时间不工作，那可能不太合适。” 有趣的是：人们会互相交流。 我和那些面试过 Oven 工作的人聊过。我和在那里工作过的人聊过。这些人互相交流。每个人都和每个人交流。消息传播得又快又广，并且所有这些消息都指向同一个内容：Jarred 是一个糟糕的管理者。沟通差、期望不切实际、缺乏同理心、毫无经验。从就业角度看，简直就是一团糟。 因此，尽管 Zig 社区成员渴望找到在上班时间编写 Zig 的工作，但大部分人才都避开了 Oven 和 Bun。 与此同时，Zig 和 Jarred 之间的裂痕开始扩大。他单纯追求生产力和初创公司的退出策略，这与我对 Zig 项目更长期的愿景越来越不一致。我记得他不停地催促我放弃所有其他优先事项，去实现一个语言服务器协议（LSP）和 VSCode 集成，而我有更宏大的计划。 然而，主要问题是代码质量。 Zig 团队定期检查用户的项目。我们阅读源代码以了解语言对用户的影响，测试变更以查看可能造成的问题，并检查性能退化。 我们在 Bun 的代码库中看到的编程实践让我们越来越感到震惊。一个一个的 hack 堆叠。滥用断言（https://kristoff.it/blog/fix-your-asserts/）。最重要的是，盲目地快速实现一个又一个功能，几乎没有花时间反思和消除 bug 及技术债。Jarred 在拥有 LLM 之前就已经在写垃圾代码了。我们不是要去监管用户的行为，但你可能注意到有人一直对着我们大喊内存安全问题。你可以想象，当某个项目的不负责任的软件工程实践正好引发了人们急于批评的论点时，我们多么希望与之保持一些社交距离。 我们徒劳地试图引导他们走向更好的编程实践。在那个功能失调的公司里，有几位杰出的英雄竭尽全力。你知道你们是谁。但你无法阻挡上涨的潮水。 到这个时候，ZSF 的所有人都认为 Bun 是一个净负债，而且这还是在 RoboBun 成为第一大贡献者之前。除了作为 Zig 编程语言公开形象代言人却实际上是“如何不写 Zig 代码”的典型例子带来的不适之外，在某个时间点他们会套现（说实话，他们模糊的“卖点云服务之类”的商业计划从一开始就是个闹剧），我们会因此受到间接的负面宣传，而我们会失去那笔定期的捐赠。 所以，当 Anthropic 的收购最终发生时，我们 ZSF 松了一口气。当捐赠悄然停止时，我们的银行账户已经为此做好了准备。当他们既没有取消与我们的月度会议，也没有出席会议时，我们并不惊讶。这段关系结束了。 （重）写的迹象已经很明显。甚至在几天之内，我们就已经怀疑会有一个 Rust 的重写。而且我们支持它！被一家大型 AI 公司收购是一种负担，因为即使只是 Claude 用 Bun 写、而 Bun 用 Zig 写这种间接联系，也会导致大量随意的垃圾贡献（https://kristoff.it/blog/contributor-poker-and-ai/），以及大量品味低下的 AI 爱好者涌入 Zig 社区，他们必须被告知将 LLM 输出粘贴到论坛帖子中是反社交的行为。有那么一刻，我担心 Zig 的身份会通俗地被称为一种与 AI 关联的编程语言。 当 Jarred 宣布用 Rust 重写时，我们欣喜若狂。这好得令人难以置信。我必须承认，我原本不认为技术能实现这个把戏。但他做到了，现在我正隐喻性地从一只写着“尝起来像不再是问题”的杯子里啜饮美味的茶。 ## 关于那篇博文 那篇博文写得非常专业。它几乎就像一家市值数万亿美元的公司的营销部门在这篇文章上押下了重注。 然而，我还是要挑几个刺。 这里呈现了一种二分法：你必须要么选择“风格指南”，要么选择编程语言特性来避免 bug。这种花招将读者的注意力从消除 bug 的主要方法上转移开：投入工程资源来解决它。你给 TigerBeetle 的功劳远远不够。很简单，他们投入了时间来查找和消除 bug，他们努力与 ZSF 保持健康的关系，而 Bun 没有这样做。 那篇博文认为，未经审查的百万行代码之所以可以发布，是因为测试套件足以捕捉所有问题。那么，为什么你们又说 Zig 代码中有那么多烦人的 bug？测试套件足以捕捉一切的问题去哪里了？它不足以捕捉 Zig 代码中的 bug，却足以捕捉 100 万行未经审查的垃圾代码？ 性能提升被归因于 LTO，而 Zig 在 Bun 存在之初就支持 LTO。它曾经默认启用，直到我们遇到太多 LLVM bug——这些 bug 同样影响 Rust。我们可能曾试图告诉你们尝试启用它，但你们不听。我们有很好的建议，真是的！ 文章声称他们在对 Zig 代码进行 fuzzing 测试，而我们在通话中整个 Bun 团队告诉我们他们并没有进行任何 fuzzing 测试。这似乎完全是捏造。 博文概述了大量为减小二进制大小所做的工程工作，以更好地证明“Bun 在 Rust 中更好”。但所有这些工程工作都与重写无关。我认为这正是博文花了这么长时间才出现的原因——你们在做那些从一开始就应该在 Zig 代码库中完成的工程工作。多年来我们一直警告你们滥用 `comptime`。我们甚至专门做了这个时间报告工具（https://ziglang.org/download/0.15.1/release-notes.html#Web-Interface-and-Time-Report），供需要审计 `comptime`/`inline` 用法和编译时间的项目使用。 我注意到你们没有提及编译速度。Zig 编译器项目大约有 60 万行代码——大约与重写前的 Bun 规模相同——而我在干净缓存下从头构建只需要 16 秒，之后每次通过增量编译进行编辑只需要 90 毫秒。重写后的 Bun 对应的测量结果是多少？ ## 今天我们学到了什么？ 稍微放远一点看，我想明确几点。 第一，我真心感谢 Bun 给予 ZSF 的捐赠。我们把这些钱花在了支付贡献者开发 Zig 的工作上（https://ziglang.org/news/2025-financials/）。 第二，实际上我对 Jarred 没有任何个人批评。他的品味和我不同，他对生活的追求也与我不同。但我认为他目前确实过得很开心且成功。他找到了如何实现生活中所有想要的目标的方法。他可以在自己生产力狂热的梦中生活，他可能已经超级富有了。他拥有小科技名人的地位。 说实话，我认为他做得很好，我对他没有任何恶意。 话虽如此，我很高兴我们的商业利益不再纠缠在一起！一旦互联网停止公开争论这个重写对 Bun 是好是坏——基于语言选择——我相信我们之间的互动就到此为止了。 ¯\\\_(ツ)\_/¯ （https://www.youtube.com/watch?v=v7gi57NJDds） 感谢阅读我的博文。