我对 Bun 重写为 Rust 的看法

博客文章的语气与专业性

• 许多人认为 Zig 创建者的回应带有很强的个人色彩：他直接点名 Bun 维护者的管理方式、工作风格以及“草率”的代码，而不是只聚焦于技术问题。
• 也有人把这些看作是专业层面的批评而非人身攻击，认为如果不谈 Bun 的发展轨迹，就无法谈它的负责人。
• 一个相当大的群体觉得这篇文章“尴尬”或“小题大做”，说这让他们更不愿意采用 Zig；也有人觉得，与“企业公关腔”相比，这种坦率反而令人耳目一新。
• 讨论的焦点之一是，重大项目的领导者是否对社区负有在公开场合更克制、更“专业”的表达义务，即便是在个人博客上。

技术争论：Zig vs Rust 与内存安全

• 有人指出，Zig 文章的核心论点是：bug 主要靠工程投入来消除，而不是靠语言选择；批评者把这和 C/C++ 中长期存在的“只要小心就行”论调相提并论。
• 许多偏向 Rust 的评论者反驳说，编译期保证（所有权、借用检查、RAII）可以消除整类 bug，而这些问题仅靠纪律很难避免。
• 也有人指出，Bun 的 Rust 移植仍在少量代码中使用了“unsafe”，但另一些人认为，至少 unsafe 区域是明确标记的，并且可以随着时间被审计或缩减。

AI、LLM 代码与项目价值观

• 一个主要分歧点是 Zig 严格反对 LLM 的立场（尤其是在贡献方面），而 Bun/Anthropic 则拥抱 AI 辅助重写。
• 支持 Zig 立场的人认为，AI 驱动的“快速推进”文化会产生难以维护的垃圾代码；另一些人则认为，完全拒绝 AI 是教条主义且自我设限。
• 有人猜测这次重写主要是 Anthropic 模型的营销展示；也有人认为即便没有这一层原因，它也迟早会发生。

Zig 的治理、生态与未来

• 多位评论者把 Zig 的领导风格与其他 “BDFL” 语言相比，担心单一且观点鲜明的把关者会限制功能、贡献者以及主流采用。
• 也有人认为，Zig 明确并不追求大众流行，而是追求一种特定哲学：手工打磨的系统编程、缓慢而审慎的变更、远离 VC 和 AI。
• 有人担心，把托管迁到 Codeberg 并强制执行强硬的反 AI 规范，可能会削弱网络效应和长期相关性；支持者则说，可持续性和价值观比增长更重要。

Bun、代码质量与模糊测试争议

• 一些人赞同 Zig 一方的观点，认为 Bun 最初的 Zig 代码看起来很赶工，充满了“补丁叠补丁”，而且它的“快速推进”文化与 Zig 的理念相冲突。
• 也有人说，如果一位高知名度的 Zig 用户在内存 bug 上都如此吃力，这本身就说明 Zig 是否适合大型、快速变化的项目值得怀疑。
• 一个具体冲突是：Zig 的帖子称 Bun 捏造了关于 fuzzing 的说法；Bun 的维护者则用链接回应，展示了 Fuzzilli 集成和基于 fuzz 发现 bug 的 PR。
• 评论者指出，这一时间线并不清楚：在早期 Zig–Bun 通话时，fuzzing 可能并不存在，后来才加入，因此双方或许都各有部分正确，但许多人认为最初“捏造”这一指控还是有些过头。

对两个项目的认知影响

• 一些读者因此对 Rust 和 Bun 更加同情，认为 Rust 重写文章技术性更强，而 Zig 的回应则更情绪化。
• 也有人说，这一事件证实了他们对 Bun 的不信任（重 AI、VC 支持、“slop”），并增强了他们对 Zig 更有原则、节奏更慢的做法的兴趣。
• 还有人指出，不论谁“对”，把这种程度的个人冲突公开化，可能都会让双方潜在的采用者和贡献者望而却步。