10 月 20 日，Cloudflare 官方博客宣布：他们正与 VoidZero 合作，把 TypeScript 编译器移植到 Rust，项目名叫 tsrs，在 oxc 工具链下孵化。同配置对比下，最多快 8 倍、内存省 70%。注意，发起方不是某个社区团队，而是 Cloudflare——TypeScript 最大的生产用户之一，自己下场。
这篇文章拆四件事：tsrs 的来龙去脉；8 倍快、70% 省内存这组数字是怎么比出来的；官方为什么点名 Rust；以及它跟上周发过的 ts-rust（LLM 驱动移植）到底差在哪。
谁在做，做什么
博文写得很清楚：Cloudflare 和 VoidZero 正与 Owner.com 的 Max Schwenk 合作推进 tsrs，项目孵化在 oxc-project 之下，并与 TypeScript 团队“紧密协作”。他们把立场放在最前面——这不是 fork。TypeScript 团队保留语言设计与演进方向的全部决定权，Rust 版必须严格跟随上游实现，否则会“逐渐散架并失去兼容”。所以 tsrs 的产品定位是执行层：同一种语言、同一套检查，跑得更快、更省资源。
过去多年，社区里出现过不少把 TypeScript 移植到其他语言的尝试，但因为复杂度太高，真正成功的只有一份——TypeScript 团队自己那次从 JavaScript 到 Go 的移植。而现在，“前沿 AI 模型可以在几天内几乎独立完成大规模移植”，于是出现了一堆带着 slop 味的分叉、忠实移植、彻底重构的 Rust 或 C++ 版本。tsrs 属于“官方用户亲自干”的这一档。
8 倍快、70% 省，这组数怎么来的
官方给出的基准是：在同样数量的类型检查 worker 下，tsrs 相比 TypeScript 7.0 最多快 8 倍、内存少用约 70%。博文专门强调，此前社区流传的一些移植基准“经常因为机器更大、选项不同”而失准，所以这次是和 TypeScript 团队一起拉齐配置之后跑的。这个细节比数字本身更关键——同配置对照才是可比的数。
一致性这条同样值得钉死：tsrs 移植的是 Go 版编译器（tsgo），Go 代码就是规格。在 TypeScript 官方 conformance 套件上，13,458 个 error 基线全部匹配，12,779 个 .types/.symbols 基线全部匹配，剩余 4 个不匹配来自测试框架层面的偏差。仓库还附了 VS Code 代码库的实测：64 核机器上比 tsc 7 快 17.7 倍、内存效率高 2.8 倍，比 bun check 快 1.55 倍。8 倍/70% 是 8 核 CI 机器的数据，换到 64 核峰值能到 17.7 倍——所以“最多 8 倍”说的是标准对照机的数，不是性能上限。
还有一组反直觉的数字：TypeScript 7.1 beta 已经比 7.0 快最多 2.5 倍，其中一部分优化就是由 tsrs 反向回流到 TS 官方实现的。也就是说，双方并不是竞争关系。tsrs 这边试验出来的编译优化，一部分正在流回官方编译器——移植方和语言方共享收益，这是这种合作形态里最稳的结构。
为什么点名 Rust
博文里“为什么不是 Go（TS 自己的移植）就够了”这一段值得细读。理由是 Wasm：把 Go 程序编到 Wasm 里，垃圾收集器要跟着一起编；Rust 的内存模型让 Wasm guest 和 host 之间的内存交互是直接的。这是语言层面的结构性差异，不是优化空间的问题——在浏览器里直接跑完整开发环境，正是 Cloudflare 明确写下的目标场景。
落到 Cloudflare 自己的栈里，这个选择也很一致：Vite、Rolldown、Oxlint、Oxfmt 早就是一批 Rust 工具，tsrs 只是同一个方向上的下一块。Oxc 这套工具链已经不是纸面规划——Rolldown 是 Vite 的打包器，Preact、Shopify、ByteDance、Shopee 都在用 oxlint，tsrs 则是这棵树上新长出的类型检查部分。
怎么用
目前 tsrs 已经作为实验版发布到 npm：执行 npm install tsrs 安装，再用 npx tsrs 运行。官方承认与上游还存在差异，比如诊断打印顺序，目标是 stable 之前把差异压到最小。把上周那篇 ts-rust（LLM 一周产出、官方 TS 团队到场评论）拿过来对照，这一周其实成了“TypeScript 第三份 Rust 移植”密集周：一份 AI 驱动，一份官方用户亲自驱动。下一站是在 Oxc 工具链里接入 type-aware lint，官方明确写着这是他们兴奋的方向。
两份 Rust 移植还互相做了基准：在 9 个基准项目上，tsrs 热态比 ts-rust 快 2.7 倍到 7.0 倍，内存峰值低 1.2 倍到 2.6 倍；9 个里有 8 个报错数一致，第 9 个（webpack）ts-rust 报 849 个错，tsrs 报 840 个——ts-rust 跟的是另一个 TypeScript commit，不是检查器本身的差异。AI 驱动和官方用户驱动，在速度上能差 2.7 倍起，这个对照本身比任何单一数字都说明问题：移植质量取决于移植方跟上游有多近，模型生成的那份离 upstream 远一层，性能就少一截。
判断：tsrs 的价值并不只在那 8 倍提速，而在于它验证了“最大用户下场做执行层、语言方保留决定权、优化双向流动”这种合作形态——这是 TypeScript 从 JS 到 Go 都没跑成、Rust 版却先跑出来的结构。浏览器里的完整开发环境（Rust+Wasm 的内存故事）是这份移植独有的场景。
下一篇看的是编译器另一端：另一边 Rust 编译器 2026 这一年，近 10 年的下一代 trait solver 收拢到最后一公里，LLVM 23 带来意外收益——那篇讲 rustc 内部在发生什么，可以接着读。
FAQ
tsrs 和 Oxc 是什么关系？ 孵化在 oxc-project 下，和 Vite/Rolldown/Oxlint/Oxfmt 属于同一棵工具链树；Oxc 团队已经开始重构 tsrs 代码库本身，目标是更快、更省内存、可维护。
TS 7.1 官方版本自己变快了，tsrs 会被官方版本追平吗？ 官方明确写道，TS 7.1 beta 已比 7.0 快最多 2.5 倍，且部分优化来自 tsrs 上游回流。两边走的是同一条优化路线，差距是动态的——这正说明合作不是各干各的。
诊断顺序这类差异对实际使用有影响吗？ 官方承诺 stable 前最小化差异。当前实验版的主要价值在性能与内存，日常 CI 使用可以接受差异；要 100% 匹配输出的场景可以等 stable。
参考
发表于 昨天 21:31
|
查看: 9|
回复: 0
