AI 摘要：TypeScript 团队宣布开发原生编译器，预计将编译速度提升 10 倍以上，大幅优化编辑器启动时间和内存占用。

本文宣布了 TypeScript 团队为提升性能开发的 原生编译器计划 。当前 TypeScript 在大规模代码库中面临性能瓶颈（如编译速度慢、编辑器启动时间长、内存占用高），新方案通过 将编译器移植到 Go 语言 实现，目标在 2025 年中期提供命令行类型检查预览版，2025 年底完成完整功能支持。

实测数据显示，新编译器在多个大型开源项目（如 VS Code、Playwright）中可实现 9-13 倍的速度提升 ，内存占用减少约 50%。编辑器场景下，VS Code 的项目加载时间从 9.6 秒降至 1.2 秒。此外，团队计划迁移至 语言服务器协议（LSP） 以提升跨语言兼容性，并为 AI 工具提供更高效的基础设施支持。

我们在选择 Go 时就明确知道，肯定会有人质疑我们为什么没有选择 Rust。这是一个很好的问题，因为 Rust 是一门出色的语言，如果没有其他限制，它在编写新的原生代码时是一个很强的首选。
可移植性（即能够创建一个与当前代码库算法上相似的新代码库的能力）一直是我们考虑如何实现这一目标时的关键限制。我们尝试了大量方法，试图找到一种在 Rust 中可行的表示方式来实现这种移植，但所有方法要么存在不可接受的权衡（性能、人机工程学等），要么演变成了“自己编写垃圾回收器”式的策略。有些方法几乎成功了，但往往需要大量使用不安全代码，而 Rust 中似乎没有多少基础元素的组合能够让人机工程学上轻松地将 JavaScript 代码移植过来（这样说并不令人意外——大多数语言并不优先考虑让从 JavaScript/TypeScript 移植变得容易！）。
最终，我们面临两个选择——在 Rust 中从头开始完全重写，这可能需要数年时间，并产出一个与 TypeScript 不兼容、无人能实际使用的版本；或者在 Go 中进行移植，大约一年左右就能得到一个可用的东西，在语义上高度兼容，在性能上极具竞争力。
而且，我们甚至不太清楚这么做的好处是什么（除了不必应对那么多“你们为什么没选 Rust？”的问题）。我们仍然希望有一个高度分离的 API 接口，以保持我们实现选择的开放性，因此 Go 的互操作性短板并不是特别相关。Go 拥有出色的代码生成和数据表示能力，就像 Rust 一样。Go 拥有出色的并发原语，就像 Rust 一样。单核性能也在误差范围内。虽然在 Go 中使用不安全代码可能会带来一些性能提升，但我们在不使用任何不安全原语的情况下已经获得了出色的性能和内存使用。
在我们看来，Rust 在实现其设计目标方面非常成功，但“从这个特定的 JavaScript 代码库轻松移植到 Rust”显然不是它的设计目标之一。Go 也不是，但就我们目前编写代码的方式而言，它在这方面确实表现得相当不错。
关于贡献问题，我并不是特别担心。学习如何在类型检查器中正确工作所需的努力，远比学习 Go 要多得多。

GitHub

Why Go? · microsoft typescript-go · Discussion #411

Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could...