【项目发布】

2026 年 7 月 24 日上午 5:58，jazzzooo 发布了 [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:29，kracked 回复表示虽没有 Fable 或 Sol，但支持该计划。上午 6:53，Ray - 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:32，jazzzooo 回复感谢反馈，称希望 Bun 只是粘合代码，但实际大部分是实际代码，如包管理器有 40000 行代码，所有的 Node API 和 Web API 都是用 Zig 实现的，还包含 10 - 20 个其他原生特性。仅维护现有特性，跟上 Bun 的新特性和 JSC 的更新就很困难，项目稳定后不介意重写一些小的依赖，但认为无法与像 Brotli 这样的大型成熟项目竞争，不过 Zig 完全有能力构建 Brotli。Bun 已有一些 V8 兼容性，目前不需要看那部分代码，有部分 V8 API 垫片可让一些流行的包正常工作，但远未全面覆盖，未来仍将采用这种策略。还询问关于稳定性，Jarred 做得不好的地方或自己可以改进的地方。

上午 9:40，kristoff 回复认为从软件“翻新”角度看这是个有趣的项目，很高兴 jazzzooo 实现了快速增量构建，建议写一篇博客文章展示增量重建的速度，随着增量构建逐渐支持全架构和操作系统，zsf 会加大宣传力度，包括发布演示视频。

下午 2:40，chrisbbreuer 回复称几个月前他们也有同样想法，一直在开发基于 Bun 的 Zig 版本进行分叉的 [Home]，还创建了 JSC 端口 [zig - js]，有很多改进空间，基准测试结果不错，欢迎有人参与 zig - js 的开发。

下午 4:36，habedi 回复并附上一张图片，还表示担心会被永久封禁。

下午 4:50，lynn 回复称觉得这个想法有趣，但对使用 LLM 存疑，认为这种使用方式本质上是“草率”的，最好先看看是否有足够多的人对维护这样一个项目感兴趣，而不是先假设需求存在，然后用 LLM 来启动项目。

下午 5:08，ForeverZer0 回复称 lynn 的担忧合理，作为通常反对使用 LLM 的人，也意识到用更多 AI 来修复 AI 混乱代码的讽刺之处，但理解原作者，因为在分叉这样一个存在现有问题的代码库时，只能接受现状，否则需进行大规模重写，这几乎是不可能完成的任务，还觉得这个项目发展到现在的状态很惋惜。

下午 5:12，lynn 回复表示同意 ForeverZer0 说的理解原作者只能接受现状的观点，但在想是否应该这样做，还担心如果没有一群人愿意来维护这个项目，同样的问题也会出现在这个项目上。

下午 6:00，jazzzooo 回复称目前构建仍使用 mold 进行实际链接，约占整个增量构建时间的 60%，Zig 自身的链接器有 4 到 5 个缺失的特性，阻碍了 Buz 对其的采用，会努力减少这些缺失特性的数量，相信 Zig 团队也在积极实现这些特性，一旦可行，预计构建时间将进一步缩短至 300 毫秒以内，届时将是 Zig 增量构建的一个很好展示。

下午 6:07，jazzzooo 回复询问 lynn 是否觉得自己的某些提交比较草率，欢迎提供反馈，还对 lynn 说的最好先看看是否有足够多的人对维护这样一个项目感兴趣表示怀疑，认为大多数这样的分叉项目都会因维护负担而失败，不能指望有人愿意花费数千小时手动清理这些代码，但如果能被证明自己错了会很开心。

晚上 7:41，peterino2 回复称这是近期见过最有趣的事情，让自己心情愉悦。晚上 11:02，zigster 回复表示太喜欢这个项目了，认为这是掌握 Zig、享受编程乐趣并在过程中结交新朋友的绝佳方式，就像是 Zig 开发者挑战的终极关卡。