Cruller：Bun 的 Zig 运行时，继续基于 Zig 0.16

原文 ↗ Hacker News 讨论 ↗

一个名为 Cruller 的新项目重新启用了 Bun 被放弃的、基于 Zig 的 JavaScript 运行时，目标是把其中精简后的子集打造成一个可嵌入、面向生产的引擎，服务于 Zig 生态，而不是作为完整 Bun 的替代品。评论者讨论了这种做法相较于直接使用 Node 或 JavaScriptCore 是否合理，也质疑在开发和生产中使用不同运行时的风险。这个分叉还引发了关于原始 Bun Zig 代码库代码质量、剪裁 git 历史的伦理，以及 Bun 在 Anthropic 之下转向 Rust 重写后社区分叉长期可行性的更广泛争论。

项目范围与目标

  • Cruller 被描述为将旧的、基于 Zig 的 Bun 运行时抽取并更新到 Zig 0.16，重点是为部署提供一个最小化的 JS 运行时。
  • 它刻意省略了 Bun 的一些功能，例如包管理、打包、TypeScript 转换和测试运行器。
  • 目标是作为 Zig 生态中的一个轻量、可嵌入的 JavaScript 运行时，而不是完整的 Bun 替代品。

与 Bun、Node、JavaScriptCore、Rust、Zig 的关系

  • Cruller 并不被定位为当前 Bun（现在是 Rust 版本）的竞争对手，而是作为由 Bun 开发的代码在生产环境中执行时的补充。
  • 它重新利用了 Zig 时代 Bun 代码的一部分，而不是跟随 Bun 的 Rust 重写。
  • 有人质疑为什么不直接使用 Node 或直接嵌入 JavaScriptCore，认为这种“中间人”会增加维护风险。
  • 支持者认为 Zig 包装层有其价值，并指出编译成单个二进制文件是一个重要的部署优势。

分叉的可行性与生态政治

  • 对分叉的看法不一：有人预测它会很快消失；也有人引用历史上成功的分叉案例（编译器、数据库、媒体项目、托管工具）。
  • 关于这是否“真的”算分叉也存在争论；几位评论者坚持认为，只要大量复用现有代码，那无论如何都算分叉，和宣传措辞无关。
  • 一些评论者把 Bun 的语言切换与 Zig 对 LLM 生成贡献的立场所引发的紧张关系联系起来，但线程中对具体动机存在争议，而且没有证据支持。

Git 历史与许可

  • 对该分叉采用的 squash、孤儿提交做法批评很强烈，这会丢弃上游的 git 历史和作者信息。
  • 相关担忧包括：
    • 更难调试（失去 git blame/bisect 上下文）。
    • 对许可/版权的可追溯性更弱。
  • 少数人表示他们很少使用历史记录；但许多其他人认为，在更大、更老的代码库中，历史记录至关重要。

开发与生产运行时的分歧

  • Cruller 的模式——开发时使用完整 Bun，部署时使用精简运行时——引发了担忧。
  • 多位评论者表示，由于微妙的、只在生产环境中出现的行为差异风险，他们不会在开发和生产中使用不同的运行时。

LLM 参与

  • 有一位参与者声称，该项目的 README、注释以及部分提交看起来像是 LLM 生成的；这一点被提及，但在线程中既未得到证实，也未被解决。