本文永久链接 – https://tonybai.com/2026/07/10/zig-founder-andrew-kelley-thoughts-bun-rust-rewrite
大家好，我是Tony Bai。
昨天我们详细解读了 Bun 官方发布的重写全过程（《AI 重写 Bun 为Rust全过程揭秘：101万行代码、11天、64个Claude并行开工》）。文章发布仅仅一天后，一个所有人都在等的声音出现了——Zig 语言的创造者、Zig Software Foundation 负责人 Andrew Kelley，在自己的个人博客上写了一篇相当不留情面的回应。
这篇文章的信息量远超一般的“技术观点交锋”。Kelley 花了大半篇幅回顾了 Zig 社区和 Jarred Sumner（Bun 创始人）之间长达五年、逐渐变质的关系，又用五个具体问题逐条拆解了 Bun 官方博客的技术论证。字里行间，火药味很浓。
需要先说明的是，这篇文章记录的是 Kelley 一方的说法和情绪，目前 Jarred Sumner 和 Bun 团队还没有公开回应。我们尽量原样转述双方立场，供读者自行判断。
这不只是一次技术分手，更是一段五年关系的终结
Kelley 文章的前半部分，与其说是技术评论，不如说是一份“塑料兄弟情”的完整复盘。
起点是善意的
Kelley 回忆，大约五年前 Jarred 刚加入 Zig 社区时，他形容对方带着一种“新手劲头”——横冲直撞、什么都想试，工程上不算精细，但学得飞快。Kelley 把这种状态形容为“健康”，尤其适合年轻人。随着 Jarred All in Bun，项目开始吸引大量关注——毕竟 JavaScript 是全世界最流行的编程语言，一个承诺高性能的新工具链天然自带流量。
Kelley 特别提到，Jarred 本可以选择靠社区众筹活下去，但他选择了走硅谷创投路线，拿了风险投资。即便如此，Jarred 早期对 Zig 社区一直心怀感激：在 Bun 官网上公开致谢 Zig 对其性能表现的贡献，还设立了每年 6万美元的月捐，捐给 Zig Software Foundation（ZSF）。Kelley 承认，这些都不是义务，Jarred 完全可以不做，但他做了，而且即便在这次引发争议的官方重写博客里，Kelley 认为 Jarred 对 Zig 项目表达的感激也是真诚的。
但关系从Bun拿到风投的那一刻开始变质
Kelley 的说法是，一旦 Bun 变成一家有风投背景的创业公司，Jarred 就从一个“和社区一起成长学习的开源贡献者”变成了一个“赶进度的管理者”，而正是这个身份转变，让 Kelley 对他那套“新手劲头”的观感彻底变了。Kelley 引用了一句 Jarred 早年被曝光的公开发言，大意是：Oven（Bun背后的公司）最初九个月会很辛苦，如果所谓的工作生活平衡意味着大量不工作的时间，那这份工作可能不适合你。
Kelley 说他和多位面试过 Oven、以及在那里工作过的人都聊过，得到的反馈高度一致：沟通差、期望不现实、缺乏同理心、管理经验为零。他形容这是“从雇主角度看一场彻头彻尾的灾难”，也因此，Zig 社区里那些真正愿意专职写 Zig 代码的人才，大多绕开了 Oven 和 Bun。
更深层的裂痕出在代码质量上
Kelley 说 Zig 团队会定期检视重要用户项目的源码，用来观察语言设计的实际影响、评估breaking change的风险、排查性能回归(Regression)。而团队在审视 Bun 代码库时“越看越心惊”——用他的原话形容，是层层叠叠的hack、对assert断言的滥用，以及最根本的问题：一路狂奔堆功能，几乎不留时间做反思、消灭bug和技术债。Kelley 直言，在 Jarred 接触LLM之前，他写的就已经是“糊弄式代码”了。
Kelley 补充说，Zig 团队原则上不会去干涉用户怎么写代码，但公众对内存安全问题的持续质疑，让他们不得不考虑和 Bun 保持一定的公开距离——毕竟外界普遍认为 Bun 是“用 Zig 写的代表作”，而团队内部却认为这恰恰是一个“如何写 Zig 代码”的反面教材。
团队曾尝试引导 Bun 往更好的工程实践走，也承认团队里有几位“孤胆英雄”式的贡献者在一个“运转失灵的公司”里已经尽了全力，但Kelley的评价是——个人努力挡不住整体趋势。
到这个阶段，Kelley 说 ZSF 内部已经把 Bun 视为一种“净负资产”，而这还是在 Anthropic 收购 Bun、“RoboBun”（指 Claude/AI）成为头号贡献者之前的判断。
Kelley 直白地表示：Anthropic 收购完成时，ZSF 团队“松了一口气”；月捐悄悄停掉时，团队财务上早有准备；后续 Bun 既没有正式取消和 ZSF 的例会，也没有再出现——这段关系就这样不了了之了。
Kelley 还提到一个细节：Anthropic 收购 Bun 后，由于“Claude是用Bun写的、Bun是用Zig写的”这种间接联系，Zig社区一度涌入大量“蹭AI热点”的低质量贡献和不太懂社区礼仪的AI爱好者，一度让他担心Zig会被贴上“和AI强绑定”的标签。
Kelley 甚至透露，早在 Bun 宣布重写的消息传出前几天，Zig 团队内部就已经预感到“Rust重写”要来了——而且他们是真心盼着这一天。所以当 Jarred 正式宣布要做 Rust 重写时，Kelley 的反应是“狂喜”——用他自己的话说，这几乎是“好到不真实”的解脱，他坦承自己一开始并不认为现在的技术真能做到这种程度的重写，但Jarred最终做到了。
针对官方博客，Kelley提出了五个“扎心”技术质疑
Kelley 承认 Bun 那篇重写博客“写得很专业”，专业到让他调侃像是“一家万亿美元公司的市场部押上重注写出来的文章”。但他随后逐条列出了自己不认同的地方。
质疑一：风格指南 vs 语言特性，是个假二分法
Bun 官方博客论证“为什么选Rust不选C++”时，把问题框定为“要么靠风格指南人肉把关，要么靠语言特性自动杜绝”。Kelley 认为这个框架本身就在误导读者，回避了消灭bug最主要的途径——投入足够的工程资源去找、去修。
他举了 TigerBeetle（一个用 Zig 写的高可靠性数据库项目）作为反例：人家能做到高质量，靠的是真金白银投入时间找bug、修bug，并且维持和 ZSF 的健康关系，而 Bun 团队没有做到这些。
质疑二：测试套件的说法自相矛盾
Bun 博客里论证“机械翻译+海量测试就足够兜底”，但 Kelley 反问：如果测试套件真的“足够好、能兜住一切”，那为什么 Zig 版本本身还积压了那么多恼人的bug？测试套件在 Zig 代码里“兜不住”，怎么换个场景——上百万行未经人工审查的新代码——就突然“兜得住”了？
质疑三：性能提升归功于LTO，但Zig一直支持LTO
官方博客把性能提升归功于 Rust 与 C/C++ 之间的跨语言链接时优化（LTO）。Kelley 指出，Zig 从 Bun 诞生之初就支持 LTO，而且一度是默认开启的，后来因为撞上太多 LLVM 层面的bug才关掉——而这些LLVM bug同样会影响Rust。Kelley 的说法是，Zig团队大概率早就建议过Bun启用LTO，只是没被采纳。
质疑四：fuzzing造假指控
这是最尖锐的一条。Bun官方博客里提到此前对 Bun 的Zig 代码做过模糊测试（fuzzing）。但 Kelley 说，在他们和 Bun 团队的历次沟通中，对方明确表示没有在做任何fuzzing。他把这一条称为“彻头彻尾的捏造”。
质疑五：体积优化工作和“重写”本身没关系，编译速度只字未提
官方博客花了不少篇幅讲二进制体积怎么通过各种工程手段缩小的，但 Kelley 指出，这些体积优化工作其实和“从Zig换成Rust”没有必然关系——本该在 Zig 代码库时代就完成。他认为，这也是为什么这篇博客拖了这么久才发出来：团队其实是在这段时间里补做了本该一直在做的工程功课，尤其是 Zig 团队多年来一直提醒但没被重视的 comptime 滥用问题（Zig 编译期特性，用不好会拖慢编译速度）。
Kelley 还专门指出，官方博客完全没有提及编译速度的对比数据。他给出了自己的参照系：Zig 编译器项目本身约60万行代码，规模和重写前的 Bun 相当，冷启动全量编译约16秒，增量编译单次修改约90毫秒。他反问：Bun重写成Rust之后，对应的编译速度数据是多少？
“我们没有私人恩怨，只是终于不用绑在一起了”
文章最后，Kelley 的语气缓和了不少。他表示，自己确实感激 Bun 过去捐赠的资金——这些钱被用来支付 Zig 贡献者的报酬。他也澄清对 Jarred 本人没有私人成见，只是两人对人生的追求和品味不同，并认为 Jarred 其实活成了自己想要的样子：实现了“生产力狂人”式的人生幻想，大概率已经财务自由，也有了一定的科技圈知名度。Kelley 的原话是，他觉得 Jarred 混得不错，不祝他倒霉。
但他同时也很坦率地表达了如释重负——终于不用再和 Bun 的商业利益绑在一起。他的收尾是：等互联网不再争论“这次重写对Bun到底是好是坏”，他和 Bun 之间的这段故事，也就算画上句号了。
小结
之所以写下这篇解读文章，不只是因为它够“辣”，更因为它把一个原本纯技术向的话题，拉回到了开源生态里一个更普遍、也更少被公开谈论的张力：当一个依赖上游开源项目的创业公司拿到风险投资、开始追求增长和退出节奏时，它和上游社区之间原本互惠的关系，很容易演变成互相拖累。
Kelley 的技术质疑（尤其是LTO早已支持、fuzzing造假这两条）如果属实，确实会削弱 Bun 官方博客里“重写带来质变”的部分论证基础——但目前这仍然是一家之言，我们没有看到 Bun 官方对这些具体指控的回应，也建议读者对双方各执一词的部分保持审慎判断。
不过有一点值得所有正在“依赖小众语言/小众社区做核心项目”的团队参考：无论最终谁的技术判断更站得住脚，一段关系走到公开对撕的地步，往往不是某个单一技术决策造成的，而是长期缺乏沟通、期望错位累积的结果。这可能才是这篇“分手宣言”式博客，真正值得技术团队复盘的地方。
参考资料：My Thoughts on the Bun Rust Rewrite – https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
