TypeScript 被 Rust 重写了：快 8 倍、省 70% 内存，真正的动机是 WASM
Cloudflare 宣布 tsrs——TypeScript 编译器的 Rust 移植版，快 8 倍、内存少 70%。HN 讨论挖出了三个更硬的点：速度是 WASM 沙盒需求的副产品、Rust 无 GC 难题靠永不释放的 arena 绕过、移植代码几乎全由 AI 写成。本期访谈请前端基础设施工程师聊聊，编译器竞赛的下一章到底在比什么。
这周 Cloudflare 宣布了一个叫 tsrs 的项目：把 TypeScript 编译器整个移植到 Rust，号称比 TypeScript 7.0 快 8 倍、内存少用 70%，已经能 npm install tsrs 装到试验版。这事在 HN 上拿了 609 分、334 条评论，但评论区最热的不是数字本身，而是三个更硬的问题：这移植的代码据说几乎全是 AI 写的；Rust 根本没有 GC，移植一个 GC 语言的编译器怎么做到的；以及——Cloudflare 真正想要的，可能根本不是更快，而是能跑进 WASM 沙盒的 tsc。我请来老朋友林砚——在一家大厂做过多年构建工具链和构建性能优化的前端基础设施工程师。我们聊了聊，编译器竞赛的下一章，到底在比什么。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 林砚，先帮大家把事实摆平。tsrs 到底是什么？TypeScript 不是刚被官方从 JavaScript 移植到 Go 吗，怎么又来一个 Rust 版？
林砚： 先厘清两个版本。官方 TypeScript 团队自己把 tsc 从 JavaScript 移植到了 Go，那是 TypeScript 7.0，确实已经快了 10 倍左右。而 tsrs 是另一条线：Cloudflare、VoidZero 和 Max Schwenk（Owner.com 的）在做 TypeScript 编译器的 Rust 移植，孵化在 Oxc 工具链下面，而且是跟 TypeScript 团队密切合作的。官方博客第一时间就划线：我们不是在 fork TypeScript，语言的设计和方向仍然完全由 TypeScript 团队说了算。
小听： 数字先报一下：比 TypeScript 7.0 快 8 倍，内存少 70%，条件是相同数量的 type check worker。评论区有人实测，类型检查从 10 秒掉到 0.5 秒，内存只剩四分之一。连 ChatGPT 的基础设施工程师都说要迁移。
林砚： 数字是真的，但有个容易被忽略的细节：TypeScript 7.1 beta 自身就比 7.0 快 2.5 倍，而且其中一部分优化是从 tsrs 反哺回去的。TypeScript 团队的 Dan Rosenwasser 亲自下场回帖，说得很实在——速度提升不全是语言选择的问题，tsrs 做实验时发现的优化思路，有一些被上游拿走了。所以这不是"Rust 打败 Go"，而是两个实现在互相喂招，官方 tsc 也会跟着变快。tsrs 承诺找到的性能优化会贡献回 TypeScript 的 Go 代码库，大家共赢。
快 8 倍是结果，动机才是故事。
小听： 聊到动机，评论区 sheepscreek 那条点赞很高：他说这事的真正起点根本不是"做一个更快的 Rust 版 TypeScript"，而是 Cloudflare 需要一个能跑在纯 WASM 沙盒里的 tsc。唯一的现成选项是把 Go 版 tsc 导出到 WASM，但那会把整个 Go runtime 打包进去。试了 Rust，发现居然比官方实现还快——速度是副产品。
林砚： 这条抓住了要害。Go 编译到 WASM，必须把 Go 的垃圾回收器一起编译进去，体积和启动成本都下不来。而 Rust 的内存模型让 WASM guest 和 host 之间的内存交互非常直接，不需要拖着一个 GC 跑。Cloudflare Workers 早就支持 WASM，前几周还宣布了原生 Rust 支持。他们的算盘是：把整个开发工具链跑在 Workers 的紧循环里，或者直接跑在浏览器里、嵌入式设备、IoT 上——一个内存占用极小的完整开发环境。配上 agent，就能在完全沙盒化的环境里端到端跑开发流程。这才是 tsrs 对 Cloudflare 的战略价值：编译器只是第一块多米诺骨牌。
小听： 技术上最硬的一块：Rust 没有 GC，而 TypeScript 编译器原本是 GC 语言写的。评论区 afdbcreid 翻了 tsrs 的 PORTING.md，说他们用了一种独特的内存模型——对长生命周期的对象用"永不释放"的 arena，相当于伪造了一个 GC。
林砚： 对，这正是当年 TypeScript 团队没选 Rust 的原因：从 GC 语言移植到无 GC 语言，通常要重构数据结构。tsrs 的做法很务实——编译器里大量对象（比如类型信息）的生命周期基本就是"整个编译过程"，那就别费劲做精细的所有权设计，直接扔进 arena，编译完统一丢掉。这在 Rust 里是 sound 的，因为 arena 的借用规则是明确的。这招不算优雅，但非常符合移植的经济学：目标是"行为一致"，不是"写出教科书级的 Rust"。顺带一提，这也是 AI 擅长的地方——大规模、机械、但要求处处一致的改写。
编译器住进沙盒，才是真正的野心。
小听： 说到 AI，博客原文里最扎眼的一句就是："frontier AI models can now do large-scale ports almost independently in a matter of days"——前沿模型几天就能近乎独立地完成大规模移植。评论区 egonschiele 说自己天天用 TypeScript，看到速度提升很兴奋，但看到这句很不舒服：他正在写自己的语言，花了大量时间做架构决策，而有人"零代码"几天就移植了一个编译器。他问：我这种工作方式是不是正在消失？
林砚： 这是整场讨论里最值得认真对待的焦虑。原文还列了现状：已经出现了 slopfork（粗制滥造的 fork）、faithful port（忠实移植）、re-architected version（重构版），说明需求是真实的。但 egonschiele 的担心混淆了两件事：移植（port）和设计（design）。tsrs 恰恰证明了这一点——Cloudflare 反复强调"我们不 fork，语言设计权归 TypeScript 团队"，移植的前提是有人先把"TypeScript 应该是什么"想清楚。AI 让"把一个想清楚的东西换一种语言重写"变得便宜，但没有让"想清楚"本身变便宜。他的语言设计工作不会消失，只是"重写一遍"的护城河没了。
小听： 还有个维护层面的问题：TypeScript 语言在演进，移植版怎么跟上？官方博客说会跟 Theo Browne 把 tsc-rs 和 tsrs 合并成一个包，支持 LSP，还要沿用他们维护 Vinext（Next.js 移植版）的那套流程。
林砚： Vinext 那套流程值得单独说：每天早上一个 agent 审上游 diff、开 tracking issue；每天晚上重新生成兼容性矩阵，把上游测试套件跑一遍；发现差距后，agent 自己定位两边代码的差异、写复现、移植测试、提修复。Cloudflare 把同一套搬到 TypeScript 上。这其实是整件事最有时代特征的部分：AI 写移植只是上半场，下半场是 AI 维护移植——让移植版永远追着上游跑而不分叉。以前"port 会烂掉"是因为人跟不上上游的演进速度，现在维护本身也被自动化了。
小听： 最后问个开发者的实际问题：评论区有人说 Bun 和 Node 现在都能直接跑 TypeScript，连编译步骤都省了，那 tsc 快 8 倍对我有什么用？
林砚： 这得分开看。运行时类型剥离（type stripping）解决的是"跑起来"，tsc 解决的是"检查对"。Bun/Node 不做类型检查，你写错类型它们照样跑。tsrs 快，省的是 CI 里、编辑器里、agent 并发开几十个 worktree 时的类型检查时间。sinameraji 那条实测很有代表性：想大规模跑并发 agent，每个 agent 都要做类型检查，内存和时间直接决定你能并行开多少个。所以 tsrs 真正的客户画像，可能不是"我本地开发"，而是"我的 agent 舰队"。
小听： 一句话收尾？
林砚： 编译器竞赛比的不再是语言，而是"开发环境能住进哪里"——WASM 沙盒、浏览器、Workers、agent 的 worktree。tsrs 的 8 倍速是入场券，真正的赌注是：当 AI 既能写移植又能维护移植，工具链的演进速度会从"年"变成"天"。TypeScript 团队这次的态度也很说明问题：不封杀、不恐慌，派人下场一起研究优化从哪来。最好的竞争，是让上游也变快的那种。