TypeScript 官方选 Go 而非 Rust 重写编译器的原因

核心前提：这次是「移植现有千万行 TS 编译器代码」，不是从零全新开发。如果从零写高性能编译器，Rust 确实更优，但移植场景下 Rust 存在底层结构性障碍，Go 是唯一能低成本、短工期做到100% 行为兼容的选择。

一、最致命：Rust 无 GC + 借用检查，和现有 TS 架构完全冲突

1. 原版 tsc 重度依赖 GC、循环 AST

   TS 编译器的 AST 是大量循环引用图结构：父节点存子、子节点反向存父、类型之间互相引用、泛型无限交叉依赖，整个代码库建立在「自动垃圾回收」之上，到处是互相指向的指针环。

   • Go：自带 GC，天然支持循环引用，指针随便互相指向，移植时数据结构几乎不用改。

   • Rust：无 GC，所有权/借用检查原生禁止循环引用。想实现循环只能用 Rc<RefCell<T>>，会大量引入 unsafe、运行时开销，还要重写整套内存模型，等于推翻原有架构重做。

2. 团队实测结论

   尝试用 Rust 做原型后发现：要么手写简易 GC（巨大工作量、性能收益打折），要么彻底重构 AST 设计；两种方案都会让工期从1年拉长到3年以上，且很难保证和原版 tsc 行为完全一致（TS 十几年积累大量细微兼容逻辑，改动架构极易出现隐性编译行为差异）。

二、移植成本：Go 语法、范式和 TS 高度贴近，Rust 割裂严重

1. 类型系统与抽象高度相似

   • Go interface ≈ TS interface；Go 结构体、函数、闭包写法和 TS 思维几乎对齐；大量逻辑可以逐块直译。

   • Rust 所有权、生命周期、trait、match 模式匹配、mut 可变标记、生命周期参数，整套思维模型和 JS/TS 完全割裂，每一段逻辑都要重新设计写法。

2. 团队学习与迭代速度

   • TS 团队本身精通 JS/TS，上手 Go 仅需几天；Rust 完整生产力学习周期数月，团队切换成本极高。

   • Go 编译速度极快，修改代码后秒构建编译器；Rust 增量编译慢，编译器本身开发迭代效率大打折扣。

三、并行编译需求：Go goroutine 开箱即用，Rust 并发样板代码繁重

重写核心目标之一：解决 Node.js 单线程瓶颈，实现多文件、多类型检查真正多核并行：

• Go：goroutine + channel 极简并发，无手动线程池、无锁复杂处理，编译器天然分片并行解析/类型检查，几行代码实现分布式任务调度。

• Rust：需要手动用 Tokio 线程池、Arc/Mutex 处理共享 AST，并发安全样板代码极多，原有单线程逻辑改成并行要大规模重构。

四、工程与微软内部战略因素

1. 交付优先级：先可用，再极致性能

   Rust 理论上限性能更高（预估比 Go 再快 20%-50%），但微软判断：1年内交付10倍提速的稳定兼容版本，比3年后交付15倍提速但兼容性存疑的版本价值大得多。前端生态数百万大型项目无法承受编译器行为偏移带来的大量编译报错。

2. 微软内部 Go 生态成熟

   Azure、VS Code 后端、云服务大量使用 Go，团队已有成熟 Go 运维、发布、跨平台打包流程；Rust 在微软内部基础设施配套不如 Go 完善。

3. 跨平台单二进制分发

   Go 一键输出 Windows/macOS/Linux 静态单文件，适配 tsc 全平台分发需求；Rust 交叉编译、静态链接配置繁琐。

五、补充：为什么前端工具（SWC/Biome/Turbopack）能用 Rust？

两者场景完全不同，不能类比：

1. SWC、Biome 是从零全新实现，从底层就设计无循环 AST、基于引用计数内存模型，不用兼容十几年旧编译器的边角行为；

2. TypeScript 官方 tsc 首要约束是100% 对齐原有编译输出、类型推导、报错规则，任何架构重构都会破坏兼容性，这是 Rust 无法低成本解决的硬门槛。

极简总结

• 选 Go：保留原有 AST 与 GC 架构、低成本移植、一年交付、完美兼容、原生简单多核并发；

• 弃 Rust：无GC+借用检查不支持循环AST，必须推翻整套内存模型，移植变全新重写，工期翻倍、兼容性风险巨大。

如果未来微软从零开发下一代全新 TypeScript 编译器，Rust 会是有力候选；但本次 Project Corsa 移植改造，Go 是唯一务实解。