Bun 官方：PR #30412 - Rewrite Bun in Rust / #30683 - Remove .zig source files

大新闻

Bun 的作者 Jarred Sumner 成功的给我们搞了个大新闻，此前还像是“一场实验”的 Zig 到 Rust 迁移，已经以 PR #30412 Rewrite Bun in Rust 合入了主分支。一次性改动 2188 个文件，新增超过 100 万行，删除 4024 行。

呃，看到这个 PR 被 Merge 了的时候，我就不是很想做技术评价了。。。截止写作，这个 PR 在 GitHub 收获了 628 点赞，423 点踩。其实看到 PR 被合了我当然是惊讶了一会儿的，但是对 Bun 官方的路线不意外，从非技术因素上讲可以说是由来已久了。

我本来以为作者最激进，激进到家了也就是把 Rust 代码一把合并进来，Rust 和 Zig 在未来几个月或者更长时间内共存发版，一起维护，渐进的替换。中午我还在问别人，一样的人员、资金投入，维护两个版本，对迭代的影响怎么办。紧接着就是没想到中的没想到，Jarred 又开了 PR #30683 Remove .zig source files; rename $zig macros to$rust。。。

这个 PR 目前还在 Open 状态，但是，呃，看到这个 PR 之后我回去给原 PR 点了个踩。。。

My View

我对 Zig 在语言和社区上都了解不多，对 Rust 社区还是有一点感情的。在这一点上我似乎对 Bun 的未来选择 Rust 这件事并没有先天的敌意。但是，Bun 这件事实在做的太着急了。几天前还是 “一场实验”，“这些代码大概率全部丢弃”，几天之后合近主线还要把 Zig 代码都清掉。。。作为一个社区项目（我承认这个项目个人因素很浓，我也知道 Bun 现在被 Anthropic 收购了），我觉得没有路线图、没有讨论，在还有 1.8k 个 PR 开着的情况下如此的仓促行事，确实给我一种不被尊重的感觉（就是表达一个感觉，不要骂我和我有什么关系…… 我可以指社区的一份子）。

原有 Issue 和 PR 里那些基于 Zig 实现细节提出的问题怎么办？还挂着的一千多个 PR 怎么办？它们是逐个 rebase、逐个重写，还是大量关掉重来？对一个快速发展的开源项目来说，作者当然有权做方向选择，但如此毫无章法随心所欲的大迁移无疑会把社区贡献者过去积累的上下文全部打乱。

对这个行为本身，我目前确实情感矛盾且偏向负面。

插个题外话，我对 Vibe Coding 本身也情感矛盾复杂 …… 但是考虑到离了 Coding Agent 我现在就是个废人，我对 AI Coding 肯定态度是积极正面的。我对「Vibe」的理解可能是更加许愿式、放任自流的那种感觉。从这个角度说，我不喜欢 Zig 社区对 AI 极端保守的态度，也很反感这种一夜 port 的 AI 神话。

题外话的题外话，至少我的博客我还在坚持手作！！！

“由来已久”

作为 Zig 社区的 “独苗” （姑且这么说？），Zig 和 Bun 的社区风格长期差异巨大。这里面还有多少技术因素我都觉得难说。

去年年底的时候，Zig 拖家带口离开了 GitHub，作者 Andrew Kelley 写了一篇措辞非常情绪化的公告（后来似乎改掉了不少）。这场迁移当然是有现实考量的，主要是 GitHub Actions 的调度问题（vibe-scheduling —— 社区群众造梗能力无穷啊），但是 Andrew Kelley 的措辞让人很担心他被自己的有些政治化的态度冲昏了头脑。Bun 这边被 Anthropic 收购了，众所周知，A 社这家公司也经常比其它科技公司显得多一点点政治意味 …… 我知道这么说有点牵强，但是大家就弱化一下的理解，这两边的 Ideology 好像略有一点不相容啊。

具体到对待 AI 的态度上，Zig 社区的态度极端不友好。vibe-scheduling 这个词嘲笑 GitHub 的 bugs，你也可以认为也在嘲笑 Vibe Coding. Zig 项目本身是禁止 AI-generated PR、Code、Issue、Comment 的。但是收购 Bun 的 Anthropic 可是 Claude Code 的作者啊。。。Bun 团队多次发推，说自己把 Zig 的性能提升了若干倍，但是不能合回上游，因为我们是用 LLM 写的。。。话说成这样，带点嘲讽，沾点贴脸开大，多少感觉已经有点私人恩怨在里面了。

那边觉得这边是 Slopfarm, Take your slop elsewhere，这边觉得那边一群 “手写教” 狂热人士，AI denialism. 所以我说，我一直觉得 Bun 有一天会转向，如果 Bun 团队出个路线图，渐进的用 Rust 进行替换，并行维护一段时间进行过度，像 TypeScript 那样的重写，我觉得是完全能接受的，甚至是在我意料之内、我会感到开心会支持的。

Bun 与软件基建的未来

功能覆盖

首先 Bun 不是一个普通库，而是 JavaScript 运行时、包管理器、测试工具、打包工具等能力揉在一起的基础设施。它的行为兼容性、平台差异、边界条件和生态依赖，“测试套件通过”真的能完全覆盖吗？Bun 大概在接下来一段时间要遭受海量质疑了。作为一个也到处给同学们安利介绍过 Bun 的人，我还是希望它能用实际表现经受住质疑的。

内存安全

众所周知 Bun 早期的内存泄漏问题是有点出名的。所以至今在生产环境需要做 server 的大家基本还会用 Node.js 跑，或许有人会有 Deno. Bun 主要是用来运行（加速）JavaScript 所写的工具链、在 Edge Runtime 执行代码。这些环境基本开一个进程用完就丢掉，不会有长期驻留进程，内存泄漏问题也就相对不是问题，漏呗漏呗，执行结束了操作系统给你一波带走。但是可以想到的是 Bun 官方是想解决这个问题的。这些是我觉得 Bun 有一天会迁移到 Rust 的直觉来源之一，也是我可能会支持平稳过渡到 Rust 的原因。

不过，“迁移到 Rust 就解决内存安全问题”这个叙事并不是先天就要成立的。Rust 的安全性建立在 safe Rust 的约束之上；Bun 项目里此刻存在海量 unsafe、FFI、手写内存管理、跨语言 ABI、JSC 绑定和各种为了性能绕过抽象的代码，Rust 编译器能提供的保护就会打折扣。当然，作为底层语言工具链，没有 unsafe 很多能力是实现不了的，后面就要看这些 unsafe 是否被压缩到足够小、足够清晰、足够可审计的范围里。不知道 Claude Code 有没有遵循 Rust 社区给 unsafe 块写特别注释的好传统。

当 AI Agent 开始动我们的系统级基础设施

我愿意承认这可能是一个重要的历史节点 —— AI Agent 开始在系统级语言级的基础设施上大动干戈 —— Jarred 在这个时候冒出来做一个 “疯子” 来见证历史。但是我暂时仍然不愿意把它看成一个 Coding Agent 的“胜利”。虽然合并了，Jarred 所说的这是一场大型实验仍然不假，实验对象是一个个真实用户正在使用的运行时。