Buz – 一个使用现代 Zig 的 Bun 分支，增量构建低于 1 秒

项目概览与目标

• Buz 是 pre-Rust Bun 的一个分支，用“现代 Zig”重写，并实现亚秒级增量构建。
• 维护者正在积极清理继承来的代码库，删除死代码，并更多依赖 Zig 的 stdlib。
• 早期策略：在代码进入“正常”状态之前，不接受人工编写的贡献；LLM 被大量用于重构和“deslop”这份代码。

AI、“Slop”与代码质量

• 一些人把 Bun（尤其是 Rust 重写）视为“AI slop”的典型：大量、混乱、由 LLM 驱动且难以维护的代码。
• 另一些人强烈反对这种说法，认为 Bun 的 Rust 移植通过借用检查器提升了安全性，并不天然低质量。
• 许多评论指出，用 LLM 来清理由 LLM 帮助生成的代码颇具讽刺意味，但也有不少人表示，只要对 LLM 进行严格引导并借助工具验证，实际效果是成功的。

生态、可持续性与替代方案

• 有人怀疑在没有强大生态的情况下，Buz 能否长期维护；很多人预计大多数用户会继续使用 Bun，或者回到 Node。
• Deno 被提及为另一种现代运行时，但也有人担心它的势头以及公司的稳定性。
• 一些人认为，主要因为“全家桶”式工具链（如 Bun）而选择运行时是有风险的；在许多人看来，Node + 专门化工具已经足够好。

构建时间、Zig 与 Rust 重写之争

• Buz 的亚秒级增量构建被视为证据，证明借助 Zig 和更好的实践，快速构建一直都是可行的。
• 这与 Bun 早先对 Zig 编译时间的抱怨，以及对 Zig 编译器一个有争议的分支形成对比。
• 一些人认为从 Zig 转向 Rust 部分出于政治和生态因素；另一些人则强调 Rust 的内存安全保证。

死代码与维护

• Buz 声称已从 Bun 约 60 万行的基础代码中移除了约 1.1 万行显然无用的死代码。
• 有人对此感到震惊；也有人认为，在大型、快速演进的项目中，1–2% 的死代码很正常。
• 有人怀疑，LLM 生成的代码导致了未使用、未清理的分支和工具。

元话题：JS 工具链与 AI 疲劳

• 多位评论者表达了对层出不穷的新 JS 运行时/框架以及为寻找问题而制造的 AI 生成“解决方案”的疲惫感。
• 但也有人仍然看重 Bun/Buz，因为它们将许多工具整合到一个快速运行时中，类似于一种有明确观点、开箱即用的框架。