由 LLM 完成的 TypeScript 编译器、检查器和 LSP 的 Rust 移植

原文 ↗ Hacker News 讨论 ↗

由 LLM 驱动的 TypeScript 编译器和类型检查器到 Rust 的移植，引发了关于成本、性能和可维护性的讨论。评论者争论“40 万美元 API tokens”这一标题说法（大多由订阅补贴），比较 OpenAI 和 Anthropic 模型在这项任务上的效果，并权衡 Rust、Go 和 JavaScript 在编译器场景中的优劣，尤其是在面向 WebAssembly 时。很多人将该项目视为一个引人注目的概念验证——比官方工具链更快，但很可能不会被维护——同时也把它看作一个早期信号：在未来，大型复杂系统会经常被机器在不同语言之间自动翻译。

项目成本与 LLM 经济学

  • README 里“价值 40 万美元的 API 计费 tokens”这一说法引发了大量讨论。
  • 多条评论指出，这只是理论上的 API 等价成本；实际上是通过订阅和评估额度完成的，真实花费据报大约为 2.4 万美元，而且最终成功那一轮可能更少。
  • 有人认为引用 API 等价成本是在误导性地“炫耀”；也有人说，这有助于说明如果按标价，这项工作会花多少钱。
  • 讨论还涉及 AI 公司是否会在重度订阅用户身上“亏钱”；有人提到较高的已报告毛利率，并认为订阅至少是收支平衡的。

Rust vs Go vs JS 与 WASM

  • 一些评论指出，这实际上是对原始 TypeScript 编译器的 Go 重写再进行 Rust 移植。
  • 关于 Go 和 Rust 的争论：选择 Go 是为了易用性和便于移植；而 Rust 则被认为在性能和 WebAssembly 方面更好（更小、更快的二进制文件，最小化运行时）。
  • 也有人表示 Go 同样可以面向 WASM（尤其是 TinyGo），而且有无 GC 不能简单地被概括为“更快/更慢”。
  • 还有人认为 JS 从来就没被认真考虑为新的实现语言，这是一种错失的机会；也有人指出 TS 最初本来就是用 JS 写的。

LLM 作为程序员：质量、测试与信任

  • 这个移植项目主要由 LLM 生成，其中某个模型（Opus）在速度和进展上显著优于早期的 OpenAI 尝试。
  • 作者表示他们“从未读过一行这段代码”，这让一些评论者感到不安，认为这很不负责任；另一些人则认为，能通过完整的 TS 测试套件就已经足够。
  • 引发的担忧包括：原始测试依赖“常识”而留下的隐藏缺口；没有人类真正理解的代码的可维护性；以及在需求变化下的长期演进问题。
  • 反方观点：对于测试非常充分的系统，代理通过与测试反复迭代，可能比人类留下更少的缺口；未来的工作流也许会更偏向于添加测试，而不是手工编辑代码。

严肃性、影响与情绪反应

  • 有人认为这个项目更像一个梗/实验，未必会被维护，类似于“在微波炉上跑 Doom”，但它仍然是一个重要的能力展示。
  • 也有人强调其现实用途：据报在一些真实项目中比 tsc 快 1.6–4 倍，而且更适合 WASM 部署。
  • 情绪上的分歧很明显：一些人觉得 AI 重写“抹去了手艺感”，让这类项目不再鼓舞人心；另一些人则把重点放在，当开发成本大幅下降时，现实可行的事情会如何爆炸式增长。