Bun用Rust重写了吗？Zig vs Rust技术选型深度解析

引言：一个引发关注的重写话题

近日，Hacker News 上一则标题为「How is the Bun Rewrite in Rust going?」的讨论引发了开发者社区的广泛关注，短时间内获得了 51 个点赞和近 20 条评论。Bun 作为近年来最受瞩目的 JavaScript 运行时之一，其技术栈的任何重大变动都牵动着整个前端与后端 JavaScript 生态。

「用 Rust 重写 Bun」这样的说法本身就足够吸引眼球——它触及了 Zig 与 Rust 两种系统级语言的路线之争，也折射出社区对高性能运行时底层实现的持续好奇。

Bun 与它的 Zig 之根

Bun 究竟是用什么语言写的？

要理解这场讨论，首先需要澄清一个关键事实：Bun 目前的核心实现语言并非 Rust，而是 Zig。这一点常常被误解。Bun 由 Jarred Sumner 创立，其设计目标是提供一个「一体化」的 JavaScript 运行时，集成了运行时、打包器（bundler）、测试运行器和包管理器于一身。

Bun 选择 Zig 而非 Rust，是一个经过深思熟虑的技术决策。Zig 以其对底层内存的精细控制、与 C 的无缝互操作性以及相对简洁的语法著称。Zig 由 Andrew Kelley 于 2015 年创建，定位为 C 的现代替代品而非 C++ 或 Rust 的竞争者。它的核心设计原则包括：无隐式行为（no hidden control flow）、编译期计算（comptime）替代泛型和宏、可选的安全检查，以及最重要的——能直接 @cImport C 头文件并无缝调用 C 代码，无需编写任何绑定层。Zig 编译器本身还可以作为 C/C++ 的交叉编译器使用，这使得构建依赖大量 C 代码的项目变得异常简便。

对于需要频繁与 JavaScriptCore（Bun 使用的 JS 引擎）等 C/C++ 代码库交互的场景，Zig 提供了更低的心智负担和编译摩擦。JavaScriptCore（简称 JSC）是 Apple 开发的开源 JavaScript 引擎，最初为 Safari 浏览器的 WebKit 框架而设计。与 Google 的 V8 引擎（被 Node.js 和 Deno 采用）不同，JSC 采用了多层编译架构——从低延迟的解释器（LLInt）到逐级优化的 JIT 编译器（Baseline JIT、DFG JIT、FTL JIT），在启动速度和峰值性能之间取得平衡。Bun 选择 JSC 而非 V8，正是看中了它更快的冷启动特性和更低的内存占用，这对命令行工具和短生命周期脚本尤为重要。Zig 与 JSC 的 C++ 接口之间几乎零摩擦的互操作能力，使得 Bun 能够高效地集成这一庞大的引擎代码库。

为何会出现「用 Rust 重写 Bun」的说法？

正因为 Bun 的技术选型与主流「Rust 高性能工具链」叙事形成了鲜明对比，社区中反复出现关于「Bun 是否应该、或是否正在用 Rust 重写」的讨论。这类话题本质上反映了开发者对两种语言在系统编程领域优劣的持续辩论——Rust 拥有更成熟的生态、更强的内存安全保证和更庞大的社区，而 Zig 则以编译速度和工程简洁性吸引了一批忠实拥趸。

社区讨论的核心焦点

Zig 与 Rust 的语言之争

从讨论的实际内容来看，核心议题并非「Bun 真的在被重写」，而更多是围绕语言选择的技术哲学展开。

支持 Rust 的观点通常强调：

• 生态成熟度：Rust 拥有 Cargo、crates.io 等完善的工具链和海量第三方库
• 内存安全保证：Rust 的所有权（Ownership）系统是其最核心的创新，通过三条编译期规则——每个值有且仅有一个所有者、所有者离开作用域时值被释放、值可以被借用但借用期间不能被修改（或反之）——在不依赖垃圾回收的前提下消除了数据竞争、悬挂指针和双重释放等内存安全问题。这套机制被称为「零成本抽象」，因为所有检查都在编译期完成，运行时无额外开销。但代价是开发者需要与借用检查器（borrow checker）频繁交互，特别是在处理复杂的数据结构和并发模式时，学习曲线相当陡峭。
• 社区规模：更大的贡献者池意味着更好的可持续性和招聘便利性

为 Zig 辩护的一方则指出：

• 与 C 的互操作性：Bun 深度依赖 JavaScriptCore 等 C/C++ 组件，Zig 在这方面摩擦更小
• 编译性能：Zig 的编译速度通常快于 Rust，对大型项目的开发体验至关重要
• 底层控制力：对于运行时这类需要极致性能优化的场景，Zig 提供了直接而透明的控制

成熟项目很难「推倒重来」

你可能没注意到，一个已经成熟、拥有大量用户的项目要进行语言级别的完整重写，代价极其高昂。软件工程历史上，大规模重写往往伴随着巨大风险。Joel Spolsky 在 2000 年的经典文章《Things You Should Never Do》中将其称为「软件公司所能犯的最严重战略错误」，Netscape 6 的从零重写导致公司失去浏览器市场份额就是典型案例。相比之下，Mozilla 从 Firefox 中逐步用 Rust 替换 C++ 组件（如 Stylo 样式引擎、WebRender 渲染器）的渐进式策略，被认为是更稳健的做法。

Bun 的代码库经过多年积累，围绕 Zig 构建了大量底层基础设施。即便 Rust 在某些维度更有优势，「重写」的投入产出比往往难以证明其合理性。对 Bun 而言，即便未来确有部分模块采用 Rust，也更可能采用渐进式混合方案，而非一次性推倒重来。这也是为什么此类讨论更多停留在「假设」和「探讨」层面，而非实际的工程路线图。

语言选择背后的工程权衡

系统编程没有银弹

这场讨论给我们的最大启示是：在系统编程领域，语言选择从来不是非黑即白的。

Rust 和 Zig 各自代表了不同的设计哲学——Rust 优先保证安全性，即使这意味着更陡峭的学习曲线和更长的编译时间；Zig 则优先追求简洁与控制，将更多责任交给开发者。

对于 Bun 这样的项目而言，Jarred Sumner 选择 Zig 显然是基于对具体需求的判断：需要与现有 C/C++ 引擎深度集成、需要快速迭代、需要对性能有像素级的掌控。这种务实的选择比追随语言潮流更为重要。

「用 Rust 重写一切」背后的社区心态

「用 Rust 重写 X」几乎已经成为技术社区的一种文化现象，甚至有了自己的缩写——「RIIR」（Rewrite It In Rust）。从命令行工具到操作系统组件，Rust 重写的浪潮层出不穷。其成功案例包括 ripgrep（替代 grep）、fd（替代 find）、bat（替代 cat）等命令行工具，以及更大规模的项目如 Deno（Node.js 的替代）、SWC（Babel 的替代）和 Turbopack（Webpack 的替代）。

然而值得注意的是，这些项目的成功建立在一个共同前提上：要么是从零开始的新项目，要么是对已有工具的功能性替代（而非对同一代码库的重写）。这与「重写现有成熟项目的内部实现」是截然不同的工程命题。这一方面证明了 Rust 生态的蓬勃活力，另一方面也提醒我们警惕「为了重写而重写」的技术冲动。

真正健康的技术决策，应当建立在对项目实际需求、团队能力和长期维护成本的综合评估之上，而非对某种语言的盲目崇拜。Bun 坚持 Zig 的做法，本身就是对这种冲动的一种理性回应。

结语：关注实质而非标签

这场关于「Bun 用 Rust 重写」的讨论，与其说是对某个具体工程事件的关注，不如说是开发者社区对语言选择、性能优化和工程哲学的一次集体思辨。

对于普通开发者而言，与其纠结于 Bun 是用 Zig 还是 Rust 编写的，不如关注它实际带来的价值——更快的启动速度、更简洁的工具链，以及日益完善的生态兼容性。技术的本质在于解决问题，而语言只是达成目标的手段之一。无论是 Rust 还是 Zig，能够可靠、高效地服务于用户需求的实现，才是最好的实现。