Bun 有一个公开 PR，为 JavaScriptCore 增加共享内存线程支持

原文 ↗ Hacker News 讨论 ↗

PR 的背景与范围

  • 该 PR 为 Bun 分支中的 JavaScriptCore 增加了共享堆线程支持，基于之前发布的 “Concurrent JavaScript” 设计。
  • 这不是针对上游 WebKit，而是针对 Bun 自己经过大量修改的 fork。
  • 作者确认 PR 描述完全由 LLM 生成，而且这项改动比 Bun 最近的 Rust 重写还要复杂。

共享内存线程 vs 现有 JS 并发

  • 一些评论者指出，JS 早已通过 workers、SharedArrayBuffer 和 Atomics 提供并发能力。
  • 关键区别在于：如今共享内存是可选的，而且只共享数据；而这个 PR 让整个对象堆默认变为共享。
  • 支持者认为这能实现“真正的”多线程，并带来更符合人体工学的高性能模式；批评者则认为这在常规化一种基于互斥锁的共享内存模型，而这种模型历史上非常容易出 bug。

正确性、GC 与性能担忧

  • 人们强烈担心原型链、属性定义以及整体 JS 对象图上的竞争条件。
  • 有人认为这对“大众用户”来说不安全，而 JS 的单线程模型曾是一个保护性约束。
  • GC 是一个重大问题：当前版本使用 stop-the-world 回收，大家认为这会损害延迟，并且削弱“没有单线程慢路径”的说法。
  • 历史补充：其他引擎里更早的多线程 JS 尝试曾因 GC 和互操作复杂性而被回退。

LLM、超大 Diff 与可审查性

  • 这个 PR 大约有 27 万行、涉及约 1,800 个文件；很多人认为这实际上根本无法审查。
  • 有人批评 LLM 撰写的 PR 描述风格（过长、强调“诚实”品牌、充满 em dash）。
  • 怀疑者认为 LLM 尤其不擅长并发，而用 LLM 审查 LLM 代码并不会让人放心。
  • 也有人反驳说，人类同样不擅长线程；广泛的测试、TSAN 和压力测试有帮助，而 LLM 让雄心勃勃的原型成为可能，之后再由人类打磨。

对 Bun 的信任与生产使用

  • 一些人称赞 Bun 的 DX、“一体化”工具链和速度；另一些人则报告内存泄漏、不稳定行为和未解决的 bug。
  • Bun 更广泛的 AI 驱动开发方式（Rust 重写、由 AI bot 处理 issue/PR）让一些人对其信任下降；他们计划或已经准备迁回 Node，或者考虑 Deno。
  • 有人担心，大量 AI 生成的改动再加上有限的人类监督，会让 Bun 不适合作为可靠的运行时基础。

更广泛的思考：线程、数据库与语言选择

  • 讨论集中在 JS/TS 是否适合构建高性能、多线程系统，例如 SQL 数据库。
  • 有人认为 TS + Bun + threads 可能支持有竞争力的数据库；也有人认为，与 C/C++/Rust 相比，JS 的性能层级和内存模型使这不现实。
  • 还有几位再次表示，更偏好消息传递、actor 或基于进程的模型，而不是共享一切的线程模型，理由是可维护性和可靠性。