Hacker News 中文摘要

RSS订阅

Cruller: Bun的Zig运行时，延续至Zig 0.16 -- Cruller: Bun's Zig Runtime, Continued on Zig 0.16

原文链接 | HN讨论 | 2026-07-23 23:17:38

文章摘要

Cruller是一个基于Zig 0.16的Bun运行时分支，专注于运行已构建的生产JavaScript服务器。它保留了JavaScriptCore、Bun.serve、HTTP/1-3、WebSocket等核心功能，移除了包管理器、打包器等开发工具，并采用原生Zig 0.16构建系统。

文章总结

好的，这是根据您提供的英文论坛讨论内容，用中文重新陈述的文章主要内容，已保留关键细节并删减了与主题无关的回复。

标题：Cruller：基于 Zig 0.16 的 Bun 运行时精简版

核心内容：

开发者 solenopsys 创建了 Cruller，这是 Bun 运行时的一个分支。它基于 Bun 最后一个使用 Zig 语言开发的版本，并将其移植到了标准的 Zig 0.16 版本上。Cruller 的目标是成为一个专注于生产环境的精简运行时，而非通用的 Bun 替代品。

主要特点与改动：

  1. 功能精简：Cruller 保留了运行已构建好的生产级 JavaScript 服务器所需的核心功能，包括 JavaScriptCore 引擎、Bun.serve、HTTP/1-3、WebSocket、fetch、流、Blob、Request/Response、静态文件服务以及模块解析器。同时，它移除了包管理器、打包器/转译器、Shell、测试运行器、N-API、SQL 客户端等面向开发的功能模块。

  2. 技术移植：项目将 Bun 的构建系统从旧版 Zig 的补丁集成方式，迁移到了标准的 Zig 0.16 构建图。为此，项目添加了兼容性垫片以适配 Zig 0.15 到 0.16 的 API 变化，并创建了一个代码生成嵌入模块，确保发布版本的可移植性。

  3. 设计理念：Cruller 被定位为一个“运行时”，而非全功能的 Bun。它通过一个极简的启动器加载预构建的入口文件。所有需要包安装、打包、TypeScript 转换或 bun test 的功能都被有意排除在外。

当前成果与性能：

  • 在 Linux x64 平台上，Cruller 的 ReleaseFast 精简运行时体积为 73.0 MiB，而官方 Bun 1.3.14 为 88.5 MiB，体积减少了约 18%。
  • 在 V8 Crypto 纯 JavaScript 基准测试中，两者性能相当，Cruller 的中位数性能略高约 2%，属于正常波动范围。
  • 项目目前通过了 Zig 语义检查、发布构建、CJS/ESM 入口点、Node 路径测试以及 HTTP Bun.serve 和内置 fetch() 的冒烟测试。

未来规划与讨论：

  • 开发与生产分离：开发者计划使用完整的 Bun 进行开发，而使用 Cruller 运行生产代码。这旨在将庞大的通用运行时精简为专注于特定生产需求的轻量级工具。
  • 后续目标：包括加强 HTTP/2 和 HTTP/3 支持、添加原生 ZMQ 插件、通过基于 QuickJS 的控制平面实现动态内存管理，以及将引擎打包为带有简洁 .zig 接口的动态库，以便嵌入到其他应用中。
  • 关于 Bun 转向 Rust：开发者认为 Bun 团队从 Zig 转向 Rust 的迁移并未带来显著好处，且成本高昂。相比之下，使用 AI 辅助将 Cruller 移植到 Zig 0.16 仅花费了少量时间和成本。
  • 模块化构想：开发者计划将 HTTP、TLS、ZMQ 等连接器作为独立插件，与稳定的核心解耦，以提高开发效率。同时，考虑使用 QuickJS 作为编排层来管理组件生命周期。

评论总结

根据评论内容，总结如下：

主要观点与论据：

  1. 对项目价值的质疑（评分：无，认可度中等）

    • 评论1认为Node.js已足够强大，Bun的独特功能已被移除，质疑使用此fork的必要性。
    • 评论8指出软件不必用特定语言编写，Bun在Zig和Rust中均显粗糙，质疑其意义。
    • 关键引用：
      • "What makes Bun Bun is all the things that got removed from this project."
      • "a software doesnt have to be written in your favourite language for it to work."

  2. 对fork策略的批评（评分：无，认可度较高）

    • 评论2认为应从头重写，原项目仅名称和知名度有价值。
    • 评论3指出社区分裂产生的fork通常最终消亡。
    • 评论9批评删除git历史，丢失提交作者信息，认为原始历史始终重要。
    • 关键引用：
      • "the only thing of value is the name/popularity of the original project."
      • "most forks created out of community rupture eventually die."
      • "It's always a bad decision to do that... The original history is always relevant."

  3. 对项目定位的澄清（评分：无，认可度中等）

    • 评论4解释此fork并非替代Bun，而是提取子集用于部署，开发仍用完整Bun。
    • 评论11担忧开发与生产环境差异过大，可能导致生产环境才暴露的问题。
    • 关键引用：
      • "It is extracting a subset of that codebase for deployment purposes."
      • "I don't think I would deviate my development runtime from my production runtime so significantly."

  4. 对技术选择的争议（评分：无，认可度较低）

    • 评论5质疑为何在Bun被指存在Zig不良实践后仍坚持使用Zig。
    • 评论6暗示fork行为与Zig作者Andrew Kelley的批评有关。
    • 关键引用：
      • "Bun was full of bad Zig practices. So why did they keep pushing forward with Zig?"
      • "Forking an 'embarassing project' is really something."

  5. 对项目质量的怀疑（评分：无，认可度较低）

    • 评论10指出作者评论、README和提交说明疑似由LLM生成，暗示项目缺乏真实投入。
    • 关键引用：
      • "all the author's comments seem LLM generated and so does the README."

平衡性总结：
- 支持方：评论4、11认为fork有明确用途（部署优化），但需注意环境一致性。
- 反对方：多数评论质疑其必要性、技术选择、历史处理及质量，认为原项目已足够或fork注定失败。
- 中立：评论7仅关心WSL1兼容性，未深入评价。