2026年7月8日，Bun创始人Jarred Sumner发布了一篇超过一万词的技术博文，详细记录了他如何用64个Claude Code实例、11天时间、约$165,000 API费用，将Bun的全部Zig代码（约53.5万行）机械翻译为Rust。一天后，Zig语言创始人Andrew Kelley发表了一篇题为「My Thoughts on the Bun Rust Rewrite」的回应。两篇文章在Hacker News上先后登顶，合计获得超过1,100分和600条评论。
这不是一场关于编程语言优劣的技术辩论。这是一场关于叙事权的争夺。
两篇文章，两种叙事
Jarred Sumner的博文讲了一个技术救赎的故事：Bun的Zig版本长期饱受内存bug困扰——use-after-free、double-free、内存泄漏层出不穷。Rust的borrow checker和Drop机制在编译期就杜绝了这些bug。当一个AI系统能在11天内完成过去需要三名工程师一年的语言迁移任务，之前「根本不敢做」的迁移变成了现实。叙事主线是：工具进步→问题被解决→未来更光明。
Andrew Kelley的回应讲了一个完全不同的故事：Bun的稳定性问题根源在于工程纪律缺失——「Jarred早在能用LLM之前就在写slop代码了」。Zig团队多年来反复尝试向Bun团队建议更好的编程实践，但Bun「recklessly speeding past feature after feature」的节奏没有改变。真正花了时间做质量投入的Zig项目——比如TigerBeetle——没有Bun那种频率的内存bug。
Kelley的叙事主线是：代码质量差不是Zig的错。
Andrew Kelley到底说了什么
Kelley的博文有几个关键指控：
第一，Bun的代码质量问题有长期历史。 Kelley写道，Zig团队定期检查用户项目的代码质量，而Bun的源码让他们「越来越震惊」：「hacks on top of hacks」，滥用断言，几乎没有时间做反思和bug消除。Kelley特别指出——「Jarred was already writing slop well before he had access to LLMs」。这与「AI生成代码不可靠」的常见批评方向不同：Kelley认为问题出在人，不在AI。
第二，Anthropic收购后关系迅速瓦解。 Kelley描述了Bun被Anthropic收购后双方关系的冷却过程：每月捐款悄然停止，原先定期的月会也无人出席。Zig团队对此早有心理准备——「The (re)writing was on the wall」。甚至在被收购几天后，Zig团队就预感到Rust重写即将到来，而且他们「rooting for it」——因为Bun早已从Zig的「招牌项目」变成了「净负资产」。Anthropic的间接关联导致大量AI用户在Zig社区里粘贴LLM输出，Zig团队不得不反复告知：在论坛帖子里粘贴AI生成内容属于反社交行为。
第三，Sumner的博文在夸大技术论证。 Kelley指出，Sumner将问题框定为「风格指南 vs 语言特性」的二选一是一个假二分法。TigerBeetle的成功不是因为风格指南靠代码审查来执行——它的关键规则（「启动后零分配」）通过Zig的显式分配器API在函数签名层面自执行。这不是风格问题，是架构选择。Kelley还质问：Sumner博文中展示的性能提升归因于LTO（链接时优化），但Zig已经支持LTO好几年了；你花了$165,000做重写，却没有花5分钟试一下开启LTO？
第四，100万行未经人类审查的代码是否足够可靠？ Kelley的质疑直指核心：「If a test suite is sufficient to give you confidence to throw away half a million lines of human-maintained code, why was it not sufficient to catch the bugs in the Zig version?」
Ray Myers的分析：AI估值与「编程即将消失」叙事
7月12日，前coding agent创业公司首席架构师Ray Myers在个人博客上发表了一篇被HN顶上第一的文章，将这场争论放入了一个更大的框架。
Myers的核心判断是：Anthropic已经融资$132 billion，正在逼近$1 trillion估值的IPO。在不盈利的前提下，支撑这一估值的唯一方式是出售对其「未来影响」的想象。其中一个关键叙事就是「编程正在消失，然后是软件工程，最终是大多数人类劳动」。
在这个框架下，Bun的Zig→Rust迁移不仅仅是一次技术决策——它是一场精心设计的营销事件。「Bun tried everything reasonable but was overwhelmed by memory bugs because Zig wasn’t up to the task」——这是Anthropic希望你相信的版本。「The Bun code is a mess because of their engineering decisions, including overusing AI agents to write and review everything」——这是另一种可能的真相。
Myers认为最可能的解释比这两个都更无聊：面对确实存在的内存bug挑战，管理层面有多个可选方案，而Rust重写因为恰好能为尚未发布的Fable模型做展示而被热切批准。这从商业角度完全合理，但它不是「AI拯救了烂代码」的营销故事。
Myers还指出了一个时间线上的疑点：Anthropic在5月14日就将Rust版本合入主分支，但直到7月8日才发布解释博文。两个月的延迟「conveniently allowed the story to be carried by sexy headlines like The Register’s ‘Anthropic’s Bun Rust rewrite merged at speed of AI’」。
社区反应：激烈分歧中的几条主线
Hacker News上，Ray Myers的文章在发布两小时内获得了316分、161条评论。评论区呈现出几条鲜明的意见线：
对Kelley回应的态度两极分化。 一部分用户认为他的回应是一场「meltdown」；另一部分则认为他终于说了需要有人说的话。Ryan Myers本人写道：「Some called his take a ‘meltdown’, all I can say is he’s gained a new fan today.」
「不安全Rust」的讽刺性。 多位评论者指出，这次重写是将Zig代码一行一行机械翻译成unsafe Rust——「a port to unsafe Rust, allowing a literal file-by-file migration」。而unsafe Rust和Zig在安全性上的差异，比safe Rust和Zig之间的差异要小得多。如果unsafe Rust版本已经是正确答案，那为什么Zig版本就成了问题？有评论者预测，随着代码逐渐从unsafe Rust过渡到safe Rust，「battle-testing」的积累将是关键——新代码面临的核心挑战是时间的积累，而非更多的测试用例。
AI叙事疲劳。 多位HN用户指出，Anthropic的营销叙事正在产生反效果。一个获得高分的评论写道：「The PR removing 600,000 lines of Zig code was automatically flagged by GitHub as ‘AI slop’ and closed」——这几乎是一个完美的象征。
Bun用户的务实态度。 也有评论提醒，Bun之所以有吸引力，在于它快、好用、兼容npm生态，与具体使用哪种实现语言关系不大。对用户而言，Rust版更稳定、二进制更小、启动更快——这些是实在的改善。过度聚焦于Anthropic的动机而忽略实际产出，可能错失重点。
技术争论的核心：Zig真的不适合Bun，还是Bun用错了Zig？
抛开叙事之争，技术层面有几个事实值得单独列出：
Bun的混合内存模型确实特殊。它嵌入了JavaScriptCore（C++）、BoringSSL（C）、SQLite（C）等使用手动内存管理的第三方库，同时JavaScriptCore本身运行垃圾回收。GC管理的值和手动管理的值在同一个调用栈上交汇——这是任何语言都难处理的场景。Zig的defer机制在函数内部很有效，但在跨模块、跨所有权的复杂场景中容易失效。这是任何一个不做自动内存管理的语言都会遇到的边界问题。
但TigerBeetle的存在提供了一个有力的反例。TigerBeetle是一个金融交易数据库，用Zig编写，代码极其严谨，核心规则（如启动后零分配）通过类型系统自执行。TigerBeetle的核心开发者matklad（也是Rust Analyzer的作者）在讨论中指出：Zig的分配器API设计使得可以从函数签名层面杜绝分配——「the rule is in the function signatures checked by compiler, not in the style guide checked by reviewers」。
这意味着，两边的说法可能都部分成立。Bun的独特工程需求确实增加了Zig的内存管理难度，但在这些限制条件下，Bun的工程纪律也确实没能做到TigerBeetle那种程度的质量投入。两种因素共同作用，最终指向了Rust。
从Sumner博文的技术细节来看，Rust版本的性能改进主要来自LTO、栈槽位复用和编译优化——这些Zig都可以做到，只是Bun没有做。内存泄漏的修复来自Drop的自动化——在Zig中也可以通过引入类似TigerBeetle那样的架构约定来等效实现，只是Bun也没有做。重写的根本驱动力，既有技术原因，也有组织原因和人因工程的原因。
三家公司的三重叙事
回头看，这场事件涉及三个各自在讲述自己故事的主体：
Anthropic 需要证明其AI模型能够完成人类工程师都畏惧的大型任务。Bun的Rust重写是一个完美的案例研究：11天、$165K、100万行代码。这与Anthropic对$1 trillion估值的追求紧密相连。
Zig社区 需要保护语言的声誉。当最大的Zig项目公开宣布抛弃Zig并归因于内存安全问题，潜在用户自然会问：「Zig是不是不够安全？」Kelley的回应虽然措辞尖锐，但从维护语言生态的角度看，沉默可能更不利。
Bun团队 需要解决真实存在的稳定性问题。Sumner在博文中写得很诚实：「I was tired of going to sleep worrying about crashes in Bun.」对于一个月下载量超过2,200万次的工具来说，这个担忧是有道理的。无论动机如何，结果——一个更稳定、更小、更快的运行时——对用户来说是真实的改善。
而在这三个叙事之间，真相可能正如Ryan Myers所判断的：有多条可行的技术路线，管理层面选择了那条与公司最大利益（包括营销利益）一致的路线。这件事之所以充满争议，正是因为Anthropic的叙事将这描述成「只有Rust能拯救Bun」——而事实可能只是「Rust是Anthropic最想让外界看到的解决方案」。
参考链接
- Ray Myers: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke
- Andrew Kelley: My Thoughts on the Bun Rust Rewrite
- Jarred Sumner: Rewriting Bun in Rust
- HN 讨论（Ray Myers 文章, 48889637）
- The Register: Anthropic’s Bun Rust rewrite merged at speed of AI
- HN 讨论（Andrew Kelley 文章, 48881610）
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。