Bun 弃用 Zig 改用 Rust：一封写给昔日战友的分手信
| 2026-07-11
Table of Contents
2026 年 7 月，Bun 的创始人 Jarred Sumner 在官方博客发布了一篇长文《Rewriting Bun in Rust》,宣布 Bun v1.4.0 将从 Zig 全面转向 Rust。一天后，Zig 语言的作者 Andrew Kelley 在自己的个人博客上发文回应，标题直白——《My Thoughts on the Bun Rust Rewrite》。
两篇文章放在一起读很有意思：一篇是精心打磨的”技术 + 公关”叙事，另一篇则夹杂着多年积怨的技术反驳与个人情绪。这篇文章尝试把两边的内容捋清楚，再说说这对 Bun 和 Zig 意味着什么。
Bun 为什么要放弃 Zig
Bun 从 2021 年由 Jarred 独自用 Zig 写出第一版，如今已经成长为一个体量惊人的项目:CLI 每月下载量超过 2200 万次，Claude Code、OpenCode 等热门工具都把它当作运行时，Vercel、Railway、DigitalOcean 等平台也提供官方支持。
但体量增长的另一面，是长期积累的内存安全问题——use-after-free、double-free、内存泄漏，这些原本是 C/C++ 项目的”经典病”。根源在于 Bun 要同时打交道两套内存管理体系:JavaScript 引擎 (JavaScriptCore) 是垃圾回收的，而 Zig 和 C 一样不做自动内存管理，全靠工程师在每个函数出口手写 defer 来清理。这种”GC 和手动内存交织”的场景，几乎没有语言天生擅长处理。
Jarred 给出的诊断很直接：靠 style guide 和代码审查去人工把关这类问题，治标不治本。而 Rust 的 Drop + 借用检查器，能把这类问题在编译期直接拦下，比起”寄希望于大家足够细心”,这是一种更可靠的反馈机制。
一场 11 天、64 个 Claude 并行的重写
真正让这篇博客出圈的，不是”为什么换语言”,而是”怎么换的”。
Jarred 没有选择渐进式重写，而是让 Claude Code 组织了大约 50 个”动态工作流”,高峰时 64 个 Claude 实例同时跑，持续 11 天，把 Bun 全部 1,448 个 Zig 文件机械翻译成 Rust。整个过程用了一套”implementer + 对抗式审查”的流水线：一个 Claude 负责写代码，另外两个完全看不到对方推理过程、只拿到 diff 的 Claude 专门负责挑毛病，最后由第三个 Claude 应用修复意见。文章里展示了几个被这套审查机制真正抓出来的 bug，包括异步资源释放时序错误导致的 use-after-free、时间戳转换在负数场景下的溢出问题，以及一个因为 unwrap_or 提前求值导致的 panic。
过程并不顺利：一开始多个 Claude 实例互相踩踏 git 状态，不得不禁止它们执行 git stash、git reset 等命令;编译器报错一度堆到一万六千多条，靠”逐 crate 分工”的方式让多个实例并行清理;还遇到过磁盘 I/O 配置不当导致机器一度冻结、以及为了跑通压力测试不得不用 systemd-run 做资源隔离。
最终结果:11 天内产生 6,502+ 次提交，净增约 100 万行代码，测试套件 (每个平台超过 100 万个 expect() 断言) 全部通过，0 个测试被跳过或删除。Jarred 给出的成本数字是:59 亿未缓存输入 token、6.9 亿输出 token、720 亿缓存输入 token 读取，按 API 价格计算约 16.5 万美元——他估计如果靠人工，需要 3 名熟悉代码库的工程师投入满一年。
Bun v1.4.0 最终修复了 128 个已知 bug，反复构建 2000 次的内存占用从 6.7GB 降到 609MB，二进制体积缩小约 20%,吞吐量提升 2%–5%。当然，重写也引入了 19 个新的移植性 bug(均已修复),多数源于”两种语言语法相似但语义不同”的陷阱，比如 Zig 的 assert 是函数、每次构建都会执行，而 Rust 的 debug_assert! 是宏，在 release 模式下整个表达式会被直接抹掉。
Zig 作者的回应：技术反驳，还有多年的账
如果说 Jarred 的文章是产品叙事，Andrew Kelley 的回应就是把积压已久的情绪一次性倒出来。
他先回顾了与 Jarred 的历史：早年欣赏对方那种横冲直撞的”新手能量”,也认可 Bun 曾经每年向 Zig 基金会 (ZSF) 捐款 6 万美元。但他毫不客气地批评 Jarred 作为管理者的风格——沟通差、期望不切实际——并且直言 Zig 团队长期以来对 Bun 代码库的观感很差：大量补丁式修复、滥用断言、几乎没有为消除技术债留出时间。在他看来，Bun 一度成为”如何不写好 Zig 代码”的反面教材，拖累了整个语言的声誉。所以当 Anthropic 收购 Bun、随后果然转向 Rust 时，他形容 ZSF 上下”如释重负”。
情绪之外，他也提出了几点具体的技术质疑：
- 认为”要么靠 style guide、要么靠语言特性”是个伪命题，真正消灭 bug 靠的是投入足够的工程资源认真去做，TigerBeetle(同样用 Zig 写) 就是反例证明。
- 指出一个逻辑矛盾：如果测试套件真的足够全面，能保证百万行未经人工评审的重写代码没问题，那为什么之前同样的测试套件没能拦住 Zig 代码里那么多 bug?
- 关于性能提升，他指出被归功于 LTO(链接时优化) 的部分，其实 Zig 从 Bun 诞生起就一直支持，只是后来因为 LLVM 的问题被默认关闭——而这些问题同样存在于 Rust，暗示这本是可以在 Zig 里解决的。
- 他还提到，私下交流中 Bun 团队曾承认没有做模糊测试，这与博客里”一直在勤奋 fuzz Zig 代码”的说法对不上。
- 二进制体积优化 (比如清理
comptime滥用) 这类工作，他认为本可以早在 Zig 代码库里就做，却拖到了 Rust 重写才顺带完成。 - 最后他反问对方，为什么博客只字未提编译速度这个关键指标，并给出 Zig 编译器自身 (约 60 万行代码，规模跟重写前的 Bun 相当) 从零构建 16 秒、增量编译 90 毫秒的数据作参照。
文章结尾，他特意加了一段澄清：强调这不是针对 Jarred 个人的攻击，承认对方”只是价值观和追求不同”,甚至祝对方成功幸福——但话锋一转，又说很高兴双方的商业利益从此再无交集。
这对 Bun 和 Zig 意味着什么
两篇文章合在一起看，更像是一段五年多的合作关系走到尽头后，双方各自给出的”官方说法”。
对 Bun 而言,Rust 重写大概率能兑现承诺的稳定性收益——Drop 和借用检查器确实能在编译期消灭一整类内存安全问题，这个逻辑本身不依赖于对 Jarred 个人的信任。但 19 个已知回归、约 4% 的代码仍在 unsafe 块里，说明这次迁移远非零风险，尤其 Windows 平台从文中 CI 数据看是最后才转绿的，后续版本可能还会暴露博客里没提到的边缘情况。被 Anthropic 收购后，Bun 与 Claude Code 生态的绑定会进一步加深 (Claude Code 已经切换到 Rust 版 Bun),这既带来资源保障，也意味着一个曾经的独立开源项目正在被更深地整合进大厂产品体系。这次重写本身，也很可能被行业当作”AI 辅助大规模语言迁移”可行性的标志性案例，被反复引用。
对 Zig 而言,Kelley 的文章清楚传达出一种”甩掉包袱”的解脱感——终于可以把 Zig 的公众形象和 Bun 过去被诟病的工程实践切割开，转而更多地和 TigerBeetle 这类被认为工程实践扎实的项目绑定。每年 6 万美元的捐款损失是实打实的，但显然在 Kelley 看来，声誉成本远大于这笔钱。可以预期 Zig 社区接下来会更主动地强调”用对方法 (比如 TigerStyle) 本可以避免 Bun 遇到的问题”,以此和这次事件划清界限，同时这场公开交锋大概率会促使外界重新讨论 Zig 在内存安全上的定位——它不打算走 Rust 编译期强制的路线，而是坚持”没有隐藏控制流”的哲学，这次事件既是一次公关挑战，也是一次重新讲清楚这套哲学的机会。