Bun 1.4 Rust 重写看起来不太妙？

原文 ↗ Hacker News 讨论 ↗

人们对 Bun 基于 Rust 的 1.4 重写以及其对 AI 辅助编码的高度依赖，担忧正在升温；多次错过发布目标和停滞的稳定版节奏，已经动摇了部分早期采用者的信心。支持者则反驳称，canary 版本已在 Anthropic 和 Prisma 等公司投入生产，大型重写本就会有波折，并将其视为 LLM 驱动开发的一个有前景的概念验证。这场争论不仅涉及 Bun 的稳定性和路线图，以及与 Node 和 Deno 等替代方案的比较，也触及 AI 生成代码是否能够可靠支撑关键基础设施。

关于 Bun 1.4 和 Rust 重写的总体看法

  • 一些用户表示，Bun 在实践中“非常棒”（速度快、工具集成、开发体验更好），并对 Rust 重写能改善安全性和内存泄漏持乐观态度。
  • 另一些人则报告持续的不稳定：随机构建失败、内存泄漏以及回归问题抵消了任何资源节省，使他们后悔在“严肃”项目中采用 Bun。
  • 还有少数人已经在生产环境中使用 1.4 canary（Rust 重写版），反馈基本可用，只有一些小问题（例如 REPL 渲染故障）。

发布节奏、“没发版”和沟通问题

  • 一个核心担忧是：Bun 过去频繁的发布在 Rust 重写期间停滞了约 3 个月，而此前的节奏是每 2–3 周一次。
  • 批评者认为，多次公开乐观地表示“明天就发布”之类的话，随后又延期，会削弱信任，并暗示重写出了问题。
  • 支持者则表示，重大重写自然会暂停发布；在大版本切换前谨慎打磨是合理的。
  • 也有人不满 canary 构建已在真实世界中被大量使用（例如被大型用户使用），但官方稳定版长期未出现，阻碍了保守环境中的采用。
  • 线程接近尾声时，人们指出 1.4 确实已经发布。

代码质量、死代码和指标

  • 一种批评观点引用了大量未合并 PR 和关于死代码的说法，作为重写“看起来不太妙”的证据。
  • 其他人认为这论点很弱或有误导性：
    • 据称 5k+ 的未合并 PR 并不能证明质量下降。
    • “11k 行死代码”的例子被纠正：那次删除针对的是旧的 Zig 代码库，而不是 Rust 移植版。
    • 有人认为在百万行项目中 <1% 的死代码是可以接受的；也有人说死代码应该为零，而且有 lint 工具存在。

Node、Deno 和替代方案

  • 有人询问为什么需要 Node 的替代品；他们提到 Node 不断增长的标准库、测试运行器、TS 支持以及 env-file 支持。
  • Bun 的支持者强调，集成工具链（包管理器、测试运行器、打包器、图像和 SQL 支持）以及性能，相比 Node 的工具链碎片化具有明显优势。
  • 也有人建议直接在 Node 上使用 pnpm/yarn，或者使用 Deno，以获得更高的稳定性和更符合标准。

AI 生成代码与更广泛的 AI 争论

  • 这次重写被视为 LLM 辅助开发的一个关键试金石：
    • 支持者认为，语言到语言的重写是 LLM 的自然应用场景，尤其是在测试验证下。
    • 怀疑者质疑长期可维护性、潜在的“意大利面”代码，以及在计入人工监督和 token 成本后的总体经济成本。
  • 一些人明确希望这次重写失败，以戳破“AI 会取代开发者”的炒作；另一些人则认为，人们正在反过来使劲证明或否定 LLM 的成功。