林岚｜OC 开发者生态编辑

Roc 语言负责人 Richard Feldman 在文章 Rust to Zig 中回顾，团队用大约 18 个月把约 30 万行 Rust 编译器代码重写为 Zig，并达到旧实现的功能对等。这不是一次简单的语法翻译，而是团队对构建速度、调试体验和长期维护方式的重新选择。

一句话结论： Roc 的重写说明 Zig 更适合这个团队此刻的编译器工程目标，不等于 Zig 在所有项目里都优于 Rust，更不等于 30 万行重写是一条普遍值得复制的路线。

大规模重写在软件行业名声不好，原因很实际：旧系统里藏着多年的边界条件，新代码最初往往只复现了显眼功能，却丢掉那些没人记得的行为。18 个月达到功能对等，对一个语言团队既是成果，也意味着这段时间本来可以用于新特性和生态建设。

Roc 仍然做了这个决定，是因为编译器与普通 Web 服务的权衡不同。它需要精确控制内存布局、构建过程和底层调试，同时希望贡献者能快速理解代码。Rust 的所有权和生命周期系统能在编译期阻止大量内存错误，但这种保证也会把复杂度前置；Zig 给程序员更多直接控制，编译模型更透明，代价则是更多安全责任回到团队手里。

这里有一个常被忽略的问题：如果最后只是功能对等，重写成功了吗？答案取决于目标。若目标是立刻给用户更多功能，它可能不划算；若目标是让未来十年的编译器更容易修改、编译和调试，短期功能停滞可能是一笔基础设施投资。真正的验证要看接下来几年，而不是宣布完成的那一天。

关键事实

• Roc 团队用了约 18 个月重写约 30 万行编译器代码。
• 新实现使用 Zig，并已达到旧 Rust 实现的功能对等。
• 这是特定团队、特定代码库的工程决策，不是受控的语言性能实验。

OC 判断

“某项目从 A 重写到 B”天然适合语言战争，却通常缺少可比条件。新实现会吸收旧系统的经验，也会借机删除历史包袱，所以最终改善不能全部归功于新语言。同样，原团队对 Zig 的熟悉程度、项目的底层需求和贡献者结构，也会影响结果。

Roc 最值得借鉴的不是“大家都去重写”，而是把重写成本完整说出来，并把目标定为可验证的功能对等。其他团队若考虑类似决定，至少要先回答：现有架构能否渐进修复、哪些指标会变好、迁移期间谁维护旧系统，以及失败时如何退出。

为什么重要

• 对开发者： 语言选择是安全、控制、工具链和团队经验的组合，不是单项排行榜。
• 对技术负责人： 重写需要明确指标和退出路径，不能只靠对新技术的偏爱。
• 对语言社区： 一个成功迁移案例有参考价值，但不能自动推广到不同类型的项目。

参考来源

• Richard Feldman：Rust to Zig
• Roc Programming Language