ts-rust：AI 把 TypeScript 7 编译器移植到 Rust，快 3 到 4 倍

微软 7 月 8 日发布的 TypeScript 7 用 Go 重写，官方称全量构建通常是 TypeScript 6 的 8 到 12 倍。现在有人把它又移植了一遍：开发者 Theo 用 AI 把 Go 版编译器和类型检查器搬到了 Rust，项目叫 ts-rust（npm 包名 tsc-rs）。在 T3 Code 的全量类型检查里，Rust 版默认模式 14.30 秒，快速模式 9.77 秒，Go 版 42.55 秒——分别快 2.98 倍和 4.35 倍。项目 MIT 开源，主要语言 Rust，截至 2026-10-20 有 1,382 颗星。最值得注意的一句写在 README 里：「I’ve never read a line of this code.」

核心功能

• 完整的移植范围：编译器、类型检查器和语言服务都搬了，业务代码继续写 TypeScript，只换检查与编译工具。tsc-rs 保留 Go 版的算法与行为。
• 两档速度：默认模式在 T3 Code 上快 2.98 倍；--fast 模式用更多检查线程，快 4.35 倍，代价是 CPU 时间与峰值内存上升。
• 兼容性靠测试堆出来：已通过 184,773 个从 Go 版移植过来的测试，另有语言服务与 API 的对照测试。作者称在测过的真实项目里兼容度 100%。
• 编辑器内存更省：在 10,000 次编辑的会话里，Query core 上是 232 / 249 MiB，对应 tsc 的 291 / 305 MiB；Hono 上是 314 / 324 MiB，对应 417 / 422 MiB。
• AI 写代码，人做验收：作者先试了几个月的 OpenAI 模型，烧掉超过 40 万美元的 token，兼容度卡在约 84%；换 Opus 5.5 后 10 小时做出可运行的初版，后续迭代约两周。

典型使用场景

• 大型 TypeScript 仓库的 CI：全量类型检查从分钟级压到十几秒，构建等待时间直接减少。
• 想试 WASM 里跑类型检查的人：作者列出的动机之一就是做一个能在 WASM 里高性能运行的类型检查器。
• 研究「AI 能不能移植大型编译器」的人：README 记录了完整的过程、成本与失败尝试，是一份少见的一手材料。
• 在意编辑器内存的团队：长会话下内存增长比 tsc 慢。

快速上手

npm install -D tsc-rs
npx tsc-rs -p tsconfig.json

作者自己在 README 里写了一句警告：「Be warned, I have no idea if this will actually work.」建议先在 CI 或本地跑一遍全量检查，对比诊断输出再决定是否替换。

小结

适合想缩短大型 TS 项目类型检查时间的团队，以及研究 AI 辅助移植的人。不适合把它当稳定生产工具的人——README 自己标为 early release，已知问题包括 monorepo 里 node_modules 与直接引用并存时会多报 TS6059、tsc -b 下项目间并行构建可能读到旧输出，以及编辑器长会话内存缓慢增长。

需要说清楚的是，这些速度数字来自项目自己的基准（16 vCPU、约 62 GiB 内存的 AMD EPYC，关闭输出与增量编译，预热后取 5 次中位数），我没有独立复测；快速模式的优势建立在更多线程上，CI 机器的核数与内存会直接影响结果。另外，代码是 AI 写的、作者没读过，这件事本身既是这个项目最有趣的地方，也是采用前最该想清楚的风险。Rust，MIT，1,382 星。和 Everything 那种「把商业软件逐个重写」不同，这里重写的是编译器本身，动机更多是验证模型能力。