Buz：用现代 Zig 重造 Bun，秒级增量构建
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
我正在开发 Buz，这是一个基于 Bun 在 Rust 重写前最后版本的 Zig 分支。目前项目仍处于早期阶段，远未达到生产就绪状态，但已实现了亚秒级增量构建，极大提升了开发效率。我删除了超过 11,000 行死代码，并大量重写和现代化了代码库，力求减少技术债务。由于 Bun 的代码库被戏称为'AI 生成的垃圾'，我计划广泛使用 LLM 辅助重构，但坚持由人类把控方向。目标是打造一个代码更清晰、更易维护的 Bun 替代品，最终实现无需 LLM 也能愉快维护的代码库。
我无法想象还有哪个项目的代码库会被忽视到积累 11,000 行死代码的地步。
HN 评论区
185- kristoff_it
对我来说，这个分叉最有趣的一点在于，它证明了 Bun 本来就可以一直拥有快速的构建速度。
当然，目前仍有一些限制：Zig 的增量编译尚不支持 aarch64，且只有 Linux 链接器支持二进制补丁，但征服所有主流平台只是时间问题。
- wsdn
> 为此，将广泛使用 LLM 来清理代码……
所以我们是用 LLM 来清理那些最初被 LLM 搞砸的代码吗？我们已经在 2026 年达到了技术的巅峰。
- robertlagrant
> 我删除了 Bun 中超过 11,000 行完全无用的代码。我想不出还有哪个项目的代码库会被忽视到产生 1.1 万行无用代码的地步。我还重写并现代化了代码库的部分内容，尝试更多地依赖 Zig 的标准库。在这个过程中，无数 Bug 也被修复了。
这太令人震惊了。还有谁对这么高的无用代码行数感到惊讶吗？难道这是我以前从未注意到的大型项目的通病吗？
- dmix
> 为此，我删除了 Bun 中超过 11,000 行完全无用的代码。我想不出还有哪个项目的代码库会被忽视到产生 1.1 万行无用代码的地步。
这人编程多久了？
- softwaredoug
这项努力让我想起了我在每一个重度依赖 AI 代理的编码项目中经历过的“功能开发”与“代码治理”之间的钟摆效应。
Tick（滴）：全力冲刺功能，构建出一个正确但极其混乱的版本。
Tock（答）：消化已完成的工作，清理烂代码，改进超越功能正确性的项目层面：性能、可维护性、整体的脆弱性/对变更的敏感度。
我的经验是花一天时间“氛围编程”出一个能跑的应用，然后花一周时间清理烂代码，将其变成一个可行的软件项目，能够可持续地接受更多功能而不至于像纸牌屋一样崩塌。
在 AI 时代之前，你某种程度上也做过这种事，但那时专业的人类开发者对系统有更清晰的心理模型，而且在我看来，他们切换得较慢，所以从 Tick 到 Tock 的转换没那么突兀。
- evertheylen
另一个高度相关的项目：Cruller，它同样使用了 Bun 注册前的代码库，但仅专注于生产环境的运行时部分。
链接：https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
- 1a527dd5
这就是我所谓的“表演性性能编程”。我和其他人一样热爱性能，构建时间当然应该尽可能接近 0 秒。
但这已经接近收益递减了，我敢保证，你当前的瓶颈绝对不是构建时间。
- christophilus
Bun，但由一个重视代码质量的人来管理？算我一个。不过，这确实是一项艰巨的任务。