返回
programming2026年7月9日1 分钟

Bun Rust重写:我的看法与反思

#Bun#Rust#Zig#重写#技术决策#社区关系#代码质量

1. 背景:Bun的Rust重写

Andrew Kelley - 我对Bun Rust重写的看法 (2026年7月9日) 我的Bun Rust重写思考 背景:用Rust重写Bun 历史 大约5年前,当Jarred加入Zig社区时,我形容他具有强烈的“初学者能量”。也就是说,他行动迅速,尝试了许多不同的事情,一头扎进他尚未准备好解决的问题中,导致工程成果平庸,但在此过程中学到了大量知识。我认为这是一种非常健康的态度,尤其对年轻人和学生而言。这是提升自我和学习新事物的最佳方式。当他将精力集中在Bun上时,他开始引起关注。JavaScript是世界上最流行的编程语言,因此一个前景光明的新工具链吸引了大量潜在目光。这种关注本可以以多种方式利用。例如,即使按照旧金山的标准,他也能轻松通过众筹获得稳定收入。但因为他毕业于Thiel Fellowship的思想体系而非大学,他从小就被培养成不加批判地接受硅谷思维模式,于是他接受了风险投资。从一开始,Jarred就对Zig项目表示赞赏。他在Bun网站上归功于Zig项目,称其实现了性能突破。他设立了每月向Zig软件基金会(Zig Software Foundation)的捐款,总额达每年6万美元。他本不必做这些事,但他做了,这非常酷。即使在他那篇我引用的博客文章中,他也表达了我认为对Zig项目真诚的感激之情。然而,一旦Bun成为风险投资支持的初创公司,他开始冲向终点线。现在,Jarred不再致力于一个自由开源项目,与社区一起学习和成长,而是在经营一家企业。正是在这一点上——当他突然成为管理者时——这种“初学者能量”对我来说开始变得不同。为自己选择糟糕的工作生活平衡是一回事;要求他人这样做则完全是另一回事:“Oven将是一场苦战,尤其是前九个月左右。如果工作生活平衡意味着大量时间不工作,那可能不太适合。”有趣的事实:人们会互相交流。我与那些在Oven面试过的人交谈过。我与在那里工作过的人交谈过。那些人彼此交流。每个人都与每个人交流。小道消息网络庞大而健康,充满了多汁的葡萄,所有这些葡萄都含有相同的信息汁液:Jarred是一个糟糕的管理者。沟通不畅、期望不切实际、缺乏同理心、没有经验。从就业角度来看,完全是一团糟。因此,尽管Zig社区成员渴望在上班时间用Zig编码,但大多数人才库都避开了Oven和Bun。与此同时,Zig和Jarred之间的裂痕开始扩大。他对生产力和初创公司退出策略的单一关注,与我为Zig项目制定的长期愿景越来越不一致。我记得他不断唠叨我放弃所有其他优先事项,去实现语言服务器协议(Language Server Protocol)和VSCode集成,而我有更大的计划。然而,主要问题是代码质量。Zig团队定期检查我们用户的项目。我们阅读源代码以了解语言如何影响用户,我们测试更改以查看破坏可能有多严重,并检查性能回归。我们对Bun代码库中看到的编程实践越来越感到震惊。层层叠叠的hack。滥用断言。最重要的是,鲁莽地快速推进一个又一个功能,很少花时间反思和消除bug及技术债务。Jarred在获得LLM之前就已经在编写劣质代码。现在,监督用户的行为不是我们的职责,但你可能注意到人们不断在我们面前大喊内存安全。你可以想象,我们可能希望与一个项目保持社交距离,因为其不负责任的软件工程实践恰恰招致了人们急于提出的那种批评。我们徒劳地试图引导他们走向更好的编程实践。有几个杰出的英雄在一个功能失调的公司里尽了最大努力。你们知道你们是谁。但你无法阻止涨潮。到这个时候,我们在ZSF都感到Bun是一个净负债,而这还是在RoboBun成为第一大贡献者之前。除了公开被视为Zig编程语言代言人的项目实际上是“如何不写Zig代码”的典型例子所带来的不适之外,在某个时候他们会套现(老实说,他们模糊的“卖一些云服务”的商业计划从一开始就是一场闹剧),我们会因此受到负面宣传,并且我们会停止收到那笔定期捐款。所以,当Anthropic收购最终发生时,我们ZSF松了一口气。当捐款悄然停止时,我们的银行账户已经准备好了。当他们既没有取消与我们每月会议,也没有出现时,我们并不惊讶。关系结束了。重写(或重写)的迹象已经很明显。甚至在几天内,我们就已经怀疑Rust重写即将到来。我们支持它!被一家大型AI公司收购是一种负担,因为即使Claude是用Bun编写的,而Bun是用Zig编写的这种间接联系,不仅导致了一波随意的劣质贡献,还导致了一大批无趣的AI爱好者涌入Zig社区,他们必须被告知将LLM输出粘贴到论坛帖子中是反社会的。有一刻,我担心Zig的身份会通俗地被称为与AI相关的编程语言。当Jarred宣布Rust重写时,我们欣喜若狂。这似乎好得令人难以置信。我必须承认,我原以为技术尚未成熟,无法完成这一壮举。但他做到了,现在我可以比喻性地从一个写着“尝起来像不再是问题”的杯子里喝着美味的茶。

2. 回应博客文章

回应博客文章 这篇博客文章写得非常专业。几乎就像一家万亿美元公司的营销部门在这篇文章上投入了大量资金。然而,我确实有一些异议。这里呈现了一种二分法,即你必须要么选择“风格指南”,要么选择编程语言特性来避免bug。这种手法误导读者,使其忽略了消除bug的主要方式:通过投入工程资源。你没有给TigerBeetle足够的赞誉。很简单,他们投入时间发现和消除bug,他们努力与ZSF保持健康关系,而Bun没有这样做。关于发布所有百万行未经审查代码的论点是,测试套件足够好,可以捕获所有问题。那么,为什么你说Zig代码中有那么多烦人的bug?测试套件足以捕获一切的情况发生了什么?它不足以捕获Zig代码中的bug,但足以捕获100万行未经审查的劣质代码中的bug?性能提升归因于LTO(链接时优化),而Zig在Bun存在的整个过程中都支持它。它曾经默认启用,直到我们遇到太多LLVM bug,所有这些bug也影响Rust。我们可能试图告诉你尝试启用它,但你没有听。我们有很好的建议,该死!文章声称他们正在对Zig代码进行模糊测试,而在我们的通话中,整个Bun团队告诉我们他们没有进行任何模糊测试。这似乎是彻头彻尾的捏造。博客文章概述了一系列为减小二进制大小所做的工程工作,以更好地论证“Bun在Rust中更好”。但所有这些工程工作与重写无关。我认为这正是博客文章花了这么长时间才发布的原因——你在做你从一开始就应该在Zig代码库中做的工程工作。多年来,我们一直试图警告你关于comptime滥用的问题。我们甚至专门为需要审计其comptime/inline使用和编译时间的项目制作了这个时间报告工具。我注意到你忽略了提及编译速度。Zig编译器项目大约有60万行代码——大致与重写前的Bun大小相同,我从干净缓存从头构建需要16秒,随后启用增量编译的每次编辑需要90毫秒。重写后Bun的相应测量结果是什么?

3. 我们今天学到了什么?

我们今天学到了什么? 稍微放大视野,我想澄清几点。第一,我真诚地感谢Bun向ZSF提供的捐款。我们把这些钱用于支付贡献者,让他们在Zig上工作。第二,我实际上对Jarred没有任何个人批评。他和我有不同的品味,他想要的生活目标也与我不同。但我认为他实际上在他所在的位置是快乐和成功的。他找到了如何实现他生活中所有目标的方法。他能够实现他的生产力幻想梦,他可能已经非常富有。他拥有小技术名人地位。老实说,我认为他为自己做得很好,我不希望他受到任何恶意。也就是说,我很高兴我们的商业利益不再交织在一起!一旦互联网停止公开争论基于语言选择的重写对Bun是好是坏,我相信我们的互动就此结束。¯_(ツ)_/¯ 感谢阅读我的博客文章。主页 | RSS订阅 | 赞助Zig软件基金会


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