大家好，这里是小奏 ,觉得文章不错可以关注公众号小奏技术
宣布重写
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