【项目发布】2026 年 7 月 24 日上午 5:58jazzzooo 发布了 [Buz - 使用现代 Zig 实现的 Bun 替代方案增量构建时间低于 1 秒]。该项目是其正在开发的 Bun 分支基于 Bun 用 Rust 重写之前的最后一次提交目前仍处于早期开发阶段远未达到可用于生产环境的程度。因注意到已有类似项目在 Ziggit 上发布为避免重复开发jazzzooo 决定分享自己的项目不过截至当时还未查看那个项目。【项目进展】jazzzooo 已将 Bun 移植到当前的上游 Zig 版本做了一些小补丁让增量重建正常工作。现在整个构建图都在 build.zig 中包含 JavaScriptCore 的第三方源码使增量构建时间低于 1 秒改善了项目开发流程。目标是打造可直接替代 Bun 的方案拥有更合理的代码库。为此将 Rust Bun 的所有新测试导入项目很多测试覆盖新特性和 bug 修复但还有很多测试未通过需跟上上游更新同时清理代码库、减少技术债务。【代码优化】jazzzooo 从 Bun 中删除了超过 11000 行完全无用的代码重写并现代化部分代码库更多使用 Zig 的标准库修复了无数 bug。【支持版本】该项目使用经过轻微修改的 Zig master 子模块主要是增量构建方面的修改。昨天提交的上游 Zig 版本 2b1c663 应该可以正常构建该项目。【AI/LLM 使用】目前 Bun 是典型的 AI 混乱项目继承这样的项目不易jazzzooo 在认为项目代码库达到足够合理状态前不会接受人工编写的代码贡献可能需重写大部分子系统。为此会大量使用大语言模型LLM希望在人类主导下采用更好的开发实践专注减少技术债务并编写符合 Zig 风格的代码几周或几个月后得到可展示的代码库作为 Rust Bun 1.4.0 的直接替代方案。欢迎能访问 Sol 或 Fable 的人帮助加快进度也欢迎指出 Bun 代码库中最混乱的部分jazzzooo 会尽力修复并使其现代化借此提升自己的 Zig 技能长远希望代码库在不需要 LLM 帮助的情况下也易于维护。【各方反馈】2026 年 7 月 24 日上午 6:29kracked 回复表示虽没有 Fable 或 Sol但支持该计划。上午 6:53Ray - D - Song 回复称自己开发过 JavaScript 运行时认为 Zig 或 Rust 不是 Bun 的核心部分真正构成 Bun 的是 JSC、uWebSockets、brotli、lol - html、tinycc 等 C/C 项目Zig 或 Rust 只是起到粘合作用所以对 Jarred 用 Rust 重写 Bun 不太感兴趣也认为继续维护一个 Zig 分支意义不大。他好奇 jazzzooo 是否有计划用 Zig 重写这些依赖以及是否打算为 JavaScriptCore 实现一个与 V8 兼容的 API还指出 Bun 性能出色但存在稳定性和 V8/N - API 兼容性问题若有项目能解决这些问题社区会非常欢迎。上午 7:32jazzzooo 回复感谢反馈称希望 Bun 只是粘合代码但实际大部分是实际代码如包管理器有 40000 行代码所有的 Node API 和 Web API 都是用 Zig 实现的还包含 10 - 20 个其他原生特性。仅维护现有特性跟上 Bun 的新特性和 JSC 的更新就很困难项目稳定后不介意重写一些小的依赖但认为无法与像 Brotli 这样的大型成熟项目竞争不过 Zig 完全有能力构建 Brotli。Bun 已有一些 V8 兼容性目前不需要看那部分代码有部分 V8 API 垫片可让一些流行的包正常工作但远未全面覆盖未来仍将采用这种策略。还询问关于稳定性Jarred 做得不好的地方或自己可以改进的地方。上午 9:40kristoff 回复认为从软件“翻新”角度看这是个有趣的项目很高兴 jazzzooo 实现了快速增量构建建议写一篇博客文章展示增量重建的速度随着增量构建逐渐支持全架构和操作系统zsf 会加大宣传力度包括发布演示视频。下午 2:40chrisbbreuer 回复称几个月前他们也有同样想法一直在开发基于 Bun 的 Zig 版本进行分叉的 [Home]还创建了 JSC 端口 [zig - js]有很多改进空间基准测试结果不错欢迎有人参与 zig - js 的开发。下午 4:36habedi 回复并附上一张图片还表示担心会被永久封禁。下午 4:50lynn 回复称觉得这个想法有趣但对使用 LLM 存疑认为这种使用方式本质上是“草率”的最好先看看是否有足够多的人对维护这样一个项目感兴趣而不是先假设需求存在然后用 LLM 来启动项目。下午 5:08ForeverZer0 回复称 lynn 的担忧合理作为通常反对使用 LLM 的人也意识到用更多 AI 来修复 AI 混乱代码的讽刺之处但理解原作者因为在分叉这样一个存在现有问题的代码库时只能接受现状否则需进行大规模重写这几乎是不可能完成的任务还觉得这个项目发展到现在的状态很惋惜。下午 5:12lynn 回复表示同意 ForeverZer0 说的理解原作者只能接受现状的观点但在想是否应该这样做还担心如果没有一群人愿意来维护这个项目同样的问题也会出现在这个项目上。下午 6:00jazzzooo 回复称目前构建仍使用 mold 进行实际链接约占整个增量构建时间的 60%Zig 自身的链接器有 4 到 5 个缺失的特性阻碍了 Buz 对其的采用会努力减少这些缺失特性的数量相信 Zig 团队也在积极实现这些特性一旦可行预计构建时间将进一步缩短至 300 毫秒以内届时将是 Zig 增量构建的一个很好展示。下午 6:07jazzzooo 回复询问 lynn 是否觉得自己的某些提交比较草率欢迎提供反馈还对 lynn 说的最好先看看是否有足够多的人对维护这样一个项目感兴趣表示怀疑认为大多数这样的分叉项目都会因维护负担而失败不能指望有人愿意花费数千小时手动清理这些代码但如果能被证明自己错了会很开心。晚上 7:41peterino2 回复称这是近期见过最有趣的事情让自己心情愉悦。晚上 11:02zigster 回复表示太喜欢这个项目了认为这是掌握 Zig、享受编程乐趣并在过程中结交新朋友的绝佳方式就像是 Zig 开发者挑战的终极关卡。