昨天我们已经报道，微软已准备好将 TypeScript 编译器和工具集移植到 Go，从而实现跨不同代码库的 10 倍以上编译速度。

尽管开发者们普遍称赞这一声明，但仍有一些人表示了失望，因为微软选择了 Go 而不是 Rust 来移植 TypeScript 编译器。 

X平台上的一位用户“完美“地总结了整体情绪。“比 TypeScript 获得 10 倍加速更令人震惊的是，但他们没有用 Rust 编写它，”他这样说道。 

“转眼间，Java 与 C# 之争就变成了 Rust 与 Go 之争。特别感谢 TypeScript 让这一切成为现实。”另一位网友如此说道。 

随着开发者不满情绪的不断涌现，TypeScript 的首席开发人员Ryan Cavanaugh澄清了这一立场，他们已经预料到，人们会就此展开争论。他说，虽然 Rust 被认为是一种选择，但“关键限制”是可移植性，这确保了新代码库在算法上与当前代码库相似。 

他还透露说，微软TypeScript 团队们探索了多种方法来表示代码，以便用 Rust 重写代码。但它们在性能和人体工程学方面却遭遇了“不可接受的”权衡，有些方法需要实现自己的垃圾收集器 (GC)，这增加了额外的复杂性。 

这与 Go 形成了鲜明对比，Go 会自动回收内存，也就是所谓的“垃圾收集”。Cavanaugh 说：“其中一些已经很接近了，但通常需要插入大量不安全的代码，而且 Rust 中似乎没有太多的原语组合可以实现 JavaScript 代码的人体工程学移植。” 

他解释说，团队最后有两个选择。一是使用 Rust 从头开始重写，他说这可能需要“几年时间”，而且仍然会产生一个“没人能用”的不兼容 TypeScript 版本。二是在一年内用 Go 构建一个可用的端口，它在语义上“极其”兼容，同时提供具有竞争力的性能。 

Cavanugh 还表示，Go 与 Rust 一样，具有出色的代码生成、数据表示能力和“优秀”的并发原语。 

他还指出说，Rust 在实现其设计目标方面表现出色，但“从这个特定的 JavaScript 代码库直接移植到 Rust”并不在其中，这很合理。 

他解释说，这同样适用于 Go 语言，但考虑到他们迄今为止编写代码的方式，它出人意料地，非常适合这项任务。

“我们还进行了异常大量的图形处理，特别是遍历涉及多态节点的上下行走的树。Go 在使这变得符合人体工程学方面做得非常出色，特别是在需要模仿 JavaScript 版本的代码的情况下，”他在GitHub上的一篇文章中补充道。 

“过渡到 Go 比过渡到 Rust 要简单得多”

在一次媒体采访中，TypeScript 首席架构师 Anders Hejlsberg很大程度上重申了 Cavanaugh 的言论。

他说，该项目唯一有意义的方式就是按原样移植现有代码库。原始代码库的设计基于某些假设，其中最重要的假设是存在自动垃圾收集。 

Hejlsberg 表示：“我认为这在很大程度上限制了我们的选择，并开始严格排除 Rust”，这表明 Rust 缺乏自动内存管理。 

Hejlsberg 指出，Rust 的另一个挑战是它对循环数据结构的严格限制，而 TypeScript 编译器严重依赖这种结构。该系统包括具有父引用和子引用的抽象语法树 (AST)、相互引用的符号和声明，以及自然形成循环的递归类型。 

“试图解开所有这些问题将使迁移到本机代码的工作变得难以克服，”他说。Hejlsberg 还解释说，当他们考虑所有需求时，Go 脱颖而出，成为最合适的语言。 

值得注意的是，TypeScript 是建立在 JavaScript 之上的。“如果你之前使用过 JavaScript，你会发现转换到 Go 比转换到 Rust 要简单得多，”Hejlsberg 说。 

他还表示，此次过渡对系统的影响非常温和，并不是一门需要大量仪式感的“超级复杂”语言。

“我认为 Rust 更接近于后者，”Hejlsberg这样补充道。 

作者：场长