加载失败
Bun（一个强调高性能的 JavaScript/TypeScript runtime 和工具链）原本主要用 Zig（强调底层控制与性能的系统编程语言）开发，这次话题是把它在 6 天内用 Rust（以内存安全著称的系统编程语言）做出可运行迁移。评论提到该 Rust 分支在 Linux x64 glibc（Linux 上常见的 GNU C Library 环境）上已经能通过 99.8% 的既有测试，但是否要正式替换，还取决于性能、可维护性和剩余 `unsafe` 的多少。讨论之所以发酵，是因为前一轮 HN 线程里有人说 AI 生成的代码只是“过度反应”，而这次似乎已经从争论代码风格变成了对原型质量的实际评估。评论还顺带把 Deno（另一个用 Rust 实现的 JavaScript runtime）拉来对比，讨论不同语言对 crash、memory bug 和工程维护的影响。
最初被视为“过度反应”的 AI 生成分支，现在看起来已经变成了一个能跑的 Rust 原型。有人引用 99.8% 测试通过、Linux x64 glibc 上可运行等结果，认为已经到了可以实际评估的阶段。讨论重点也从“能不能写出来”转向“性能如何、能否进测试、后续是否可维护”。还有人提醒，发起人本来就说过想把可行的 Rust 版和 Zig 版并排比较，再做决定。
一部分评论认为，Bun 过去频繁出现 crash 和 memory bug，本身就说明换成 Rust 可能是更稳妥的方向。评论还拿 Deno（一个用 Rust 实现的 JavaScript runtime）做对照，暗示 Rust 的内存安全模型更有优势。也有人追问是否有具体统计数据，认为不能把问题完全归咎于 Zig，工程实现质量同样关键。另一个折中看法是：即使 Rust 版仍有 `unsafe`，这些风险点至少会被明确暴露出来，便于集中修复。
有评论把这次迁移当作一个“用 AI port 到 Rust”的反面教材，提醒不要把 LLM（大语言模型）当成自动正确的代码工厂。后续讨论则指出，模型会强烈跟随你给的反馈回路：如果只检验逻辑正确性，它就可能忽视性能；如果把速度指标也写进测试，它也能按要求优化。这个观点的核心是，LLM 没有人的常识边界，必须把正确性、性能和约束条件明确编码进目标里。
不少人认为“6 天”只是做出了一个可工作的 prototype，真正困难的部分还在后面。接下来要把大量 `unsafe` 清掉、整理成可读可维护的 idiomatic Rust，往往比初版迁移更费时间。有人甚至把这种速度夸张成“3 年后 Linux 也能 6 天 port 到 Rust”，用玩笑强调大家对这种时间表的天然怀疑。整体语气是半认真半讽刺，承认进展但不接受把原型直接等同于成熟重写。
Zig: 一种面向系统编程的语言，强调性能、显式控制和较低层级的内存管理；Bun 原先主要使用它。
Rust: 一种强调内存安全和并发安全的系统编程语言，评论中被视为替代 Zig 的重写目标。
`unsafe`: Rust 中绕过编译器安全检查的代码块，常用于底层操作，但也意味着更高的风险和维护成本。
LLM: Large Language Model，大语言模型；这里指用于生成/修改代码的模型，是否靠谱很依赖外部约束和测试反馈。
glibc: GNU C Library，Linux 上常见的 C 标准库实现；评论提到 Rust 版在 Linux x64 glibc 环境下的测试通过率。