押了四年小众语言，他回头写了 Rust——但赢的不是 Rust

每隔几年，技术圈就会出一个"押冷门赢主流"的故事：用一个小众语言或者小众路线，做出比大厂还快的东西，被当成技术品味的胜利。Bun 这个 JS 运行时项目，过去四年就是这种故事的代表。

这两天它的一条进度更新让押冷门的人有点尴尬：作者 Jarred Sumner 公布了 Rust 重写版本在 Linux x64 glibc 平台测试通过率到了 99.8%。

数字本身不重要，重要的是这个人是谁。

2022 年 Bun 立项时，Jarred 是 Zig 语言在工业界最高调的代言人。那几年 Zig 社区出圈，一半靠 Bun。他把 Zig 当卖点写进 Bun 的介绍页：更小的二进制、更可控的内存、不依赖 C++。

四年后他自己只挑了一句话解释为什么开始切 Rust：

我累了，不想再花大把时间修内存泄漏和崩溃。

他没说 Zig 不好。他说"我累了"。

一份不需要解释的同类时间线

退一步看 JS 工具链最近五年的底层语言选择：

esbuild 用 Go，SWC、Rolldown、Turbopack、Oxc 都用 Rust。Bun 是这条线上最后一个押 Zig 的。

这条单子里有个被忽略的细节：Vercel 2023 年立项 Turbopack 选 Rust，没人问"为什么是 Rust"——因为是默认值。Bun 2022 年立项选 Zig，第一篇技术博客就花了大段解释"为什么不是 Rust"。

默认值之所以是默认值，就是因为它不需要被解释。一个选择需要不断辩护，它已经在退场的路上。

围绕这条 99.8% 吵得最凶的不是 Rust vs Zig，是另一件事——这次重写不是 Jarred 一个人手写四年完成的。

Bun 团队总共十来人。重写这个体量的项目，按传统估算至少 2-3 年人力。但实际进度明显比这快得多。社区里有人直接点穿了一句话：

LLM 最擅长两件事——翻译，和有可验证目标的任务。

把这句话拆开看：

Bun 这个项目两个条件都齐：完整的 Zig 源码 + 多年积累的测试套件。这是 99.8% 的真正成因——不是 Rust 多强，是这个项目恰好踩在 LLM 翻译的甜区。

这也解释了为什么只是 Linux x64 glibc 先到 99.8%——这是测试覆盖最饱和的平台。Windows、macOS、Linux musl、ARM 还没有数字，因为那些平台原本测试就少，LLM 翻完没有足够 ground truth 可以校准。

99.8% 是测试套件密度的副产品，不是工程师天赋的副产品。

这段我自己想了很久。

表面上 Zig 输给了 Rust 的生态——板上钉钉。但更深一层，Zig 输给的是一个 2022 年还没成型的新标准：

LLM 时代选底层语言，多了一条隐形约束——能不能被高质量翻译进/翻译出。

LLM 翻一门语言的质量取决于三件事：训练语料体量、高质量开源项目数、语法语义稳定度。Rust 三条全占，Zig 三条都差着。

这条标准 2022 年还不存在。那年 GPT-3.5 刚出，没人想得到三年后用 LLM 把一个十万行项目从一种系统语言翻到另一种是可行的。2026 年这条标准已经是默认值。今天选底层语言，潜意识里都会算：三年后想切，LLM 能不能帮我？

答案是 Rust 可以，Go 可以，Zig 不行，Crystal 不行，Nim 不行。

被排在"不行"这边的语言，会越来越难拿到新项目。新项目越少，训练语料越少，LLM 翻译质量越差——自我强化的循环。

不写代码的读者别关掉，下面这件事更普适。

长期下注一个工具、框架或语言时，除了看它本身好不好用，多问一句：它在 LLM 翻译这条标准下能不能被照顾到。

具体动作只有一个：去搜这个语言的高 star 项目数量，跟同代竞品比一比。差一个数量级要谨慎；差两个数量级，基本可以视作"LLM 不会很懂"。

押小众，过去赌的是技术品味。现在赌的是"LLM 没那么聪明所以小众也能赢"。后者比前者难赌得多。

四年前押 Zig 是技术品味问题，四年后回头写 Rust 是工程现实问题。两件事不矛盾，但读懂顺序的人，下次选型的时候会算得清楚一点。