摘要：语言选择总是个热门话题！我们最近和之前都仔细评估了很多语言选项。我们还考虑过混合方法，比如用原生语言写某些组件，同时把核心的类型检查算法留在 JavaScript 里。我们写了多个原型，尝试用不同语言表达数据，还深入研究了现有的原生 TypeScript 解析

Ryan Cavanaugh解释了为什么 TypeScript 选择用 Go 而不是 Rust 来重写：

语言选择总是个热门话题！我们最近和之前都仔细评估了很多语言选项。我们还考虑过混合方法，比如用原生语言写某些组件，同时把核心的类型检查算法留在 JavaScript 里。我们写了多个原型，尝试用不同语言表达数据，还深入研究了现有的原生 TypeScript 解析器（比如 swc、oxc 和 esbuild）的做法。明确地说，很多语言在从头重写的情况下都合适。但 Go 在多个特定标准下表现最好，值得解释一下。

最重要的是，我们需要新代码库在语义和代码结构上尽可能兼容。
我们预计未来会同时维护两个代码库一段时间。那些能让代码结构相似的语言对做代码改动的人来说是个大好处，因为我们可以轻松在两个代码库之间移植改动。

相比之下，类似Rust需要彻底重新思考内存管理、数据可变性、数据结构、多态性、惰性计算等的语言，可能更适合从头重写。但我们这次更像是在做一次“移植”，目的是保持现有行为和我们在语言中构建的关键优化。Go 的惯用写法与 TypeScript 代码库的现有编码模式非常相似，这让移植工作更容易。

Go 还提供了出色的内存布局和分配控制（包括对象和字段级别），而不需要整个代码库一直操心内存管理。
虽然这意味着有垃圾回收器（GC），但在我们的代码库中，GC 的缺点并不明显。

我们没有严格的延迟要求，不会因为 GC 暂停或变慢而受影响。批量编译时，GC 几乎可以完全忽略，因为进程在结束后就终止了。

在非批量场景中，我们的大部分前期分配（比如抽象语法树 AST）会持续整个程序的生命周期，而且我们对何时运行 GC 有很强的领域知识。

因此，Go 的模型在减少代码库复杂性方面带来了很大好处，而垃圾回收的实际运行时成本很低。

我们还有大量的图处理需求，特别是上下遍历多态节点的树结构。
Go 在这方面做得非常好，尤其是在需要与 JavaScript 版本的代码相似的情况下。

当然，Go 也有一些弱点，比如它的进程内 JavaScript 互操作性不如其他语言。
我们有计划来解决这个问题，并致力于提供一个高性能且易用的 JavaScript API。由于当前的 API 模型允许用户访问（甚至修改）几乎所有内容，我们在某些优化上受到了限制。

我们希望新代码库能让我们更自由地改变内部表示，而不必担心破坏所有 API 用户。

转向一个更注重互操作性的 API 设计，将让我们在推动生态系统的同时，仍然实现这些巨大的性能提升。

​​​​​​为何TypeScript选择用Go重写？ - 极道

来源：解道Jdon