783 comments • Comments Link

• 从 Zig 重写到 Rust 很可能早有准备：Bun 的代码库已使用与 Rust 等效的智能指针类型做了逐一映射，并且已经存在一个名为 `bun_collections` 的 Rust crate，这表明这是一次有计划的迁移而非临时试验。

• 事先创建了一个将 Zig 映射为 Rust 惯用法的 622 行指令文件。有人认为，对于改进约一百万行代码库的一致性来说，这是一笔相对较小的投入，但关于编写这些规则所需的隐性知识和迭代次数仍有疑问。

• 有人质疑"一周"时间线是否反映了真实的工作量；一些人认为重写在公开宣布前很久就已准备就绪，并且可能是 Anthropic 收购交易的一部分。

• 代码库中包含超过 10,000 个 Rust 中的 `unsafe` 块，约一半的文件含有 unsafe 代码，这令很多人怀疑 Rust 重写到底带来了多少实际的安全性提升。

• Bun 本身并不是一个 JavaScript 解释器，而是重新实现的 Node.js 库，使用 JavaScriptCore 作为其 JS 引擎，因此它更像是 Node.js 的替代运行时而非对 Node.js 的简单封装。

• Diff 行数计数里领先的 "+"（+1009257）触发了 iOS 的电话号码检测，导致整行变成超链接并可点击，考虑到上下文，有人觉得这一点颇具戏剧性。

• 重写前后代码库的行数相当（Zig 约 711K 行，Rust 约 929K 行），因此行数增加本身并非异常，尽管这种规模的变动确实前所未有。

• 测试在重写期间被修改，其中一些改动看起来值得怀疑，例如通过添加 `sleep(1)` 来让测试通过；支持者则指出没有测试被删除或移除断言，而且大多数改动实际上是在新增测试。

• 许多人认为这次重写主要是为了为 Claude 和 Anthropic 的 IPO 做营销，目的是让 LLM 生成代码看起来比实际更容易、更成功。

• 有评论者指出，将其称为"实验"可能不诚实；Jarred 在合并代码的九天前还声称"所有这些代码很可能会被完全丢弃"。

• 先做结构上的同源移植（保持与 Zig 接近），然后逐步使代码符合 Rust 惯用法，这种策略被视为机械重写的正确方法，类似于银行业从 COBOL 到 Java 的迁移。

• 对未来可维护性的担忧很普遍：当没有人能完全理解这个百万行的代码库时，Bug 如何修复、功能如何新增成为大问题。

• 这种从"试验"到合并仅 9 天的效率被许多人视为不负责任；正规做法应在停用原始代码库之前进行 shadow testing 、分阶段发布并进行广泛的现实世界验证。

• 有用户报告在 canary Rust 版本中发现了 stable Bun 中不存在的 Bug，这表明"通过测试套件"的说法并未涵盖现实世界的兼容性。

• 这次重写被视为对超过 800 名为学习 Zig 代码库投入时间的贡献者的不尊重，因为现在的贡献者需要同时学习 Rust 和一个全新的百万行代码库。

• 支持者则认为，只要代码经过适当测试并能正常运行，采用何种创建方法并不重要，而且这可能标志着软件构建方式的一个分水岭。

• 这次重写的 Token 成本估计为六位数，但由于 Anthropic 拥有 Bun，这在本质上更接近一笔营销预算而非传统的开发成本。

• 一些人认为这是 Zig 作为生产语言走向式微的开始；Bun 是其标志性项目之一，而 Tigerbeetle 现在可能是剩下的主要展示项目。

• 观察者注意到一种讽刺：一个旨在成为快速、可靠的 JavaScript runtime 的项目，竟被用作 AI 能力的营销工具。

• 关于这是否代表真正的工程进步还是"为变动而变动"的议题仍有争论；随着系统规模扩大，语言选择在稳定性与对变更的谨慎编排面前显得不那么重要。

• 合并发生时该 PR 没有任何 approval，该 PR 包含 6,755 个 commits 并涉及 2,188 个文件，使传统的代码审查几乎不可行。

• 有人担忧这会树立一个危险先例：即 LLM 可被用来绕过开源项目中的正常工程流程和社区治理。

• Claude Code 本身使用 Bun 作为其 runtime，这种事实创造了一种循环依赖：Anthropic 的旗舰产品现在运行在自己所推动的基础设施之上。

• 尽管存在争议，但仍有人保持乐观：如果 Rust 版本证明稳定，它可能比以 segfaults 闻名的 Zig 版本带来更少的内存安全问题。

这场讨论暴露了深刻的分歧：一方认为 Bun 的重写是 LLM 能力的一次突破性展示，另一方则视其为不负责任的营销噱头，优先炒作而非工程严谨性。"从实验到合并仅九天"的速度侵蚀了许多社区成员和贡献者的信任。虽然支持者强调完善的测试套件和在结构上的忠实移植是缓和因素，批评者则强调"通过测试"并不能保证现实世界的兼容性或长期可维护性。 Rust 代码中超过 10,000 个 `unsafe` 块削弱了提高内存安全性的既定目标，许多人因此得出结论，这次重写主要是为了在 Anthropic 的 IPO 前为其 AI 能力制造正面宣传。此事凸显了软件行业中更广泛的紧张关系：包括 LLM 在代码生成中的角色、维护者对社区的责任，以及当 AI 工具使快速变更在技术上变得可行时，是否应当绕过传统工程实践。 • The rewrite from Zig to Rust was likely prepared well in advance, with the Bun codebase already using smart pointer types that map 1-to-1 to Rust equivalents, and a `bun_collections` Rust crate already existing, suggesting this was a planned move rather than a spontaneous experiment.

• A 622-line instruction file mapping Zig to Rust idioms was created upfront, which some see as a relatively small cost for potentially improving consistency across a ~1M LoC codebase, though questions remain about how much tacit knowledge and iteration went into creating these rules.

• Skepticism exists about whether the "one week" timeline reflects the true effort, with some believing the rewrite was prepared long before the public announcement and was part of the Anthropic acquisition deal.

• The codebase contains over 10,000 `unsafe` blocks in Rust, with about half of all files containing unsafe code, leading many to question what safety benefits the Rust rewrite actually provides.

• Bun is not a JavaScript interpreter itself but rather a reimplementation of the Node.js library using JavaScriptCore as its JS engine, making it an alternative to Node.js rather than a wrapper around it.

• The leading "+" in the diff line count (+1009257) triggers iOS phone number detection, causing the entire line to be hyperlinked and tappable, which some find amusing given the context.

• The Bun codebase had a similar number of lines before the rewrite (Zig: ~711K lines, Rust: ~929K lines), so the line count increase isn't unusual for a rewrite, though the speed of the change is unprecedented.

• Tests were modified during the rewrite, with some changes appearing suspicious like adding `sleep(1)` to make tests pass, though defenders note that no tests were deleted or had assertions removed, and most changes were actually new tests being added.

• The rewrite is seen by many as primarily marketing for Claude and Anthropic's IPO, with the incentive to make LLM code generation appear easier and more successful than it actually is.

• Some commenters note that the "experiment" narrative may have been disingenuous, with Jarred initially claiming there was a "very high chance all this code gets thrown out completely" just nine days before merging it.

• The strategy of doing a structurally homologous port first (keeping it close to Zig) and then gradually making it idiomatic Rust is considered the correct approach for mechanical rewrites, similar to COBOL-to-Java ports in banking.

• Concerns about maintainability going forward, with questions about how bugs will be fixed and features added when no human fully understands the million-line codebase.

• The speed of the change (9 days from experiment to merge) is seen by many as irresponsible, with proper practice requiring shadow testing, gradual rollout, and extensive real-world validation before sunsetting the original codebase.

• Some users report already finding bugs in the canary Rust version that don't exist in stable Bun, suggesting the "passes test suite" claim doesn't capture real-world compatibility.

• The rewrite is viewed as disrespectful to the 800+ contributors who invested time learning the Zig codebase, as contributing now requires learning both Rust and a completely new million-line codebase.

• Defenders argue that as long as the code is properly tested and works, the method of creation shouldn't matter, and that this represents a watershed moment in how software can be built.

• The cost in tokens for this rewrite is estimated to be in the six figures, but since Anthropic owns Bun, this is essentially marketing budget rather than a traditional development cost.

• Some see this as the beginning of the end for Zig as a production language, with Bun being one of its flagship projects and Tigerbeetle now being the major remaining showcase.

• The irony that a project built to be a fast, reliable JavaScript runtime is now being used as a marketing vehicle for AI capabilities is not lost on observers.

• Questions about whether this represents genuine engineering progress or simply "churn for the sake of churn," with language choice becoming less important at scale compared to stability and careful orchestration of changes.

• The merge happened with 0 approvals on the PR, which contains 6,755 commits and touches 2,188 files, making traditional code review essentially impossible.

• Some express concern that this sets a dangerous precedent where LLMs can be used to bypass normal engineering processes and community governance in open source projects.

• The fact that Claude Code itself uses Bun as its runtime creates a circular dependency where Anthropic's flagship product now runs on vibe-coded infrastructure.

• Despite the controversy, some remain optimistic that if the Rust version proves stable, it could lead to fewer memory safety issues than the Zig version, which was known for segfaults.

This discussion reveals a deep divide between those who see the Bun rewrite as a groundbreaking demonstration of LLM capabilities and those who view it as a reckless marketing stunt that prioritizes hype over engineering rigor. The speed of the transition from "experiment" to merged code in just nine days has eroded trust among many community members and contributors. While defenders point to the comprehensive test suite and the structurally faithful nature of the port as mitigating factors, critics emphasize that passing tests doesn't guarantee real-world compatibility or long-term maintainability. The presence of over 10,000 `unsafe` blocks in the Rust code undermines the stated goal of improved memory safety, leading many to conclude this is primarily about generating positive publicity for Anthropic's AI capabilities ahead of their IPO. The situation highlights broader tensions in the software industry about the role of LLMs in code generation, the responsibilities of maintainers to their communities, and whether traditional engineering practices can or should be bypassed when AI tools make rapid changes technically feasible.