typescript选择go重写性能提升10倍,为什么不是rust呢

宣布重写

2025年3月11日TypeScript 首席架构师Anders Hejlsberg宣布将 TypeScript编译器和工具进行原生移植到Go

为什么重写

Anders Hejlsberg的解释核心原因还是因为TypeScript还无法应对超大型代码库，参与大型项目开发的开发者可能会遇到加载和检查时间过长的问题

总结原因就两个字: 性能

性能测试

官方给的运行性能测试大概快10倍左右

Codebase	Size (LOC)	Current	Native	Speedup
VS Code	1,505,000	77.8s	7.5s	10.4x
Playwright	356,000	11.1s	1.1s	10.1x
TypeORM	270,000	17.5s	1.3s	13.5x
date-fns	104,000	6.5s	0.7s	9.5x
tRPC (server + client)	18,000	5.5s	0.6s	9.1x
rxjs (observable)	2,100	1.1s	0.1s	11.0x

编译器加载代码速度能快8倍左右，并且还是在没有主动优化内存使用的情况下

为什么是go不是rust

• 官方回复

语言选择总是一个热门话题！我们广泛评估了许多语言选项，包括最近和之前的调查。我们还考虑了混合方法，即某些组件可以用本地语言编写，而核心类型检查算法则保留在JavaScript中。我们编写了多个原型，尝试在不同语言中使用不同的数据表示，并深入研究了现有本地TypeScript解析器（如swc、oxc和esbuild）所使用的方法。需要明确的是，在从头重写的情况下，许多语言都是合适的。然而，Go在考虑特定于这种情况的多个标准时表现最佳，以下将解释其中几个关键方面。

代码兼容性与结构相似性

最重要的是，我们需要使新代码库在语义和代码结构上尽可能兼容。

我们预计在未来相当长的一段时间内维护两个代码库（现有JavaScript版本和新版本）。

允许结构上相似的代码库的语言为代码更改提供了显著优势，因为我们可以轻松地在两个代码库之间移植更改。

相比之下，那些需要从根本上重新思考内存管理、变异、数据结构、多态性、惰性等的语言可能更适合从头重写，但我们将此视为一种移植，旨在保持现有行为和我们已构建到语言中的关键优化。

惯用的Go与TypeScript代码库的现有编码模式非常相似，这使得移植工作更加可行。

内存管理的高效控制

Go提供了对内存布局和分配（在对象和字段级别）的出色控制，而无需整个代码库持续关注内存管理。

虽然这意味着存在垃圾收集器（GC），但GC的缺点在我们的代码库中并不明显。

我们没有任何因GC暂停或减速而受到影响的强延迟约束。例如：

• 批处理编译可以完全放弃垃圾收集，因为进程在结束时终止。
• 非批处理场景中，我们的大部分前期分配（例如抽象语法树AST等）在程序整个生命周期内都存在，并且我们对何时是运行GC的“逻辑”时间有很强的领域知识。

因此，Go的模型在降低代码库复杂性方面为我们带来了很大的好处，同时在垃圾收集的实际运行时成本上几乎没有付出代价。

图处理与树遍历的优化

我们的代码库涉及异常大量的图处理，特别是以向上和向下的方式遍历包含多态节点的树。

Go在这方面表现得很出色，能够以符合人体工程学的方式处理这些任务，尤其是在需要与JavaScript版本的代码保持相似性的情况下。

Go的弱点与改进计划

诚然，Go在进程内JavaScript互操作性方面不如一些替代语言。

我们已经制定了即将推出的计划来缓解这一问题，并致力于提供高性能且符合人体工程学的JS API。

目前的API模型允许消费者几乎可以访问（甚至修改）任何内容，这限制了某些可能的优化。

我们希望新代码库能够为更改内部表示保留更多自由，而不必担心破坏所有API用户。

转向更深思熟虑的API设计，同时兼顾互操作性，将使我们在提供显著性能优势的同时，推动生态系统向前发展。

总结

综合来看，Go在保持代码兼容性、内存管理效率以及图处理能力等方面表现突出，非常适合我们的需求。

尽管在JS互操作性上存在不足，但通过未来的改进计划，这一弱点可以得到缓解。

因此，在众多语言选项中，Go脱颖而出，成为最适合我们当前场景的选择。

个人理解

尽管微软希望使C#成为“一切”语言,但是C#永远无法替代所有语言

官方都说了这次更应该叫移植而非重写，Go能脱颖而出除了高性能外还是GO更像TypeScript