Bun 用 Rust 重写？99.8% 测试通过率背后的故事
Bun 创始人 Jarred Sumner 最近在 Twitter 上发布了一个有趣的实验结果：Bun 的 Rust 重写版本在 Linux x64 glibc 平台上达到了 99.8% 的测试兼容性。这个消息在技术圈引发了不小的讨论。
一个实验，而非产品决策
首先需要明确的是，这只是一个技术实验。Sumner 在推文中强调，这并不意味着 Bun 会迁移到 Rust。 Zig 仍然是 Bun 的核心语言，这个 Rust 版本更多是为了验证某些架构假设。
但为什么这个实验值得关注？
性能与兼容性的平衡
Bun 自诞生以来就以「高性能 JavaScript 运行时」自居。它的卖点很明确：
- 比 Node.js 更快的启动速度
- 内置 bundler、test runner、package manager
- 对 Web 标准的原生支持
但追求性能的同时，Bun 也面临着兼容性挑战。任何偏离 Node.js 行为的地方，都会成为开发者迁移的障碍。
99.8% 的测试通过率意味着什么？这意味着在数千个测试用例中，只有极少数的行为差异。对于运行时这种复杂的基础设施来说，这是一个相当高的完成度。
Rust vs Zig：语言选择的思考
Zig 和 Rust 都是系统编程语言，但设计哲学有所不同：
| 特性 | Rust | Zig |
|---|---|---|
| 内存安全 | 编译期保证（所有权系统） | 运行时检查 + 显式分配器 |
| 学习曲线 | 陡峭 | 相对平缓 |
| 编译速度 | 较慢 | 较快 |
| 标准库 | 丰富 | 精简 |
| C 互操作 | 良好 | 原生支持 |
Bun 选择 Zig 的初衷之一，是 Zig 对 C 代码的直接兼容能力。Bun 大量依赖现有的 C/C++ 库（如 JavaScriptCore），Zig 的 @cImport 让这种集成变得非常直接。
那么 Rust 重写实验的意义何在？可能是在探索：如果使用 Rust 的严格类型系统和内存安全保证，能否在保持性能的同时提升代码的可维护性？
开发者的实际关注点
对于普通开发者来说，Bun 用什么语言实现并不重要。重要的是：
- 兼容性：我的 Node.js 项目能直接跑吗？
- 性能：启动和运行速度真的有提升吗？
- 生态：npm 包能正常安装和使用吗？
- 稳定性：生产环境能放心用吗？
从这个角度看，99.8% 的测试通过率是一个积极的信号。它表明 Bun 团队在兼容性上投入了大量精力，无论底层用什么语言实现。
我的看法
这个实验释放了几个信号：
第一，Bun 团队对技术选型持开放态度。没有因为已经选择了 Zig 就排斥其他可能性。这种务实的态度值得肯定。
第二，兼容性是 Bun 的核心竞争力之一。测试覆盖率的提升，比语言选择更能决定项目的长期成功。
第三，对于基础设施项目，语言只是实现手段。真正重要的是架构设计、测试覆盖和长期维护能力。
至于 Bun 未来会不会正式迁移到 Rust？我的猜测是短期内不会。Zig 已经为 Bun 提供了足够的性能和控制力，重写整个项目的成本远高于收益。但这个实验本身，就是对技术债务的一种保险。
文章发表于 gumi.ink