最近，Anders Hejlsberg 说了一件大事。他说，TypeScript 7.0 会有一个新的东西。这个东西就是原生编译器。它现在已经在测试了。
以前的 TypeScript 编译器，是用 TypeScript 自己写的。它运行在 V8 JavaScript 引擎上面。但是，项目越来越大。用的人也越来越多。这样一来，旧编译器就有点慢了。
Hejlsberg 团队发现了一个问题。他说：“我们很快就发现，原生编译器能让性能提升 10 倍。” 这个数字听起来很厉害。
性能提升分两部分。一半是因为原生代码本身更快。另一半是因为它用了共享内存并发技术。共享内存并发，就是让电脑的多个部分同时工作。这样就能更快地处理数据。它会帮你更快完成编译任务。
有人可能会想，那为什么不重新写一个全新的编译器呢？这样不是更干净吗？但是 Hejlsberg 说，这几乎不可能做到。
TypeScript 的类型检查器很复杂。它有很多规则。这些规则不是写在文档里的。它们只在代码实际运行的时候才体现出来。这就像一个老匠人，他的手艺不是用文字教的。而是你得看他怎么做。
如果团队重新写一个，就可能出现问题。哪怕新旧编译器只有一点点不同，也会给用户带来很多麻烦。所以，新编译器的目标很明确。它必须和旧编译器做的事情一模一样。就连那些小“毛病”也要保留下来。这样，开发者升级的时候才不会出问题。
语言选型引争议：弃 Rust、舍 C#，最终选 Go
团队给原生编译器选语言时，发生了一点小争议。Hejlsberg 透露了他们为什么做这个选择。
他们没有选 Rust 语言。因为 Rust 有两个问题。第一个是它不支持循环数据结构。但是，团队在移植代码时需要这种结构。比如，一个类型可能包含另一个类型，而那个类型又反过来包含第一个类型。这就是循环数据结构。第二个是 Rust 没有自动垃圾回收。自动垃圾回收能自动清理不再用的内存。这在移植代码时很重要。没有它，团队就要手动管理内存。这会很麻烦。
团队也试过用 C#。C# 是 Hejlsberg 自己设计的语言。但是，他们最后选了 Go 语言。他说 Go 语言和 JavaScript 很像。它们在语法和设计思路上都很像。这让很多 C# 社区的人不理解。他们问：“Hejlsberg 为什么不用自己的 C# 呢？”
Hejlsberg 没有直接回答这个问题。他只是说：“很多人觉得我们应该选别的语言。但是我们选对了工具。过去一年的实践证明了这一点。”
我的看法是，选择 Go 是一个很实用的决定。Go 语言简洁。它有高效的并发处理能力。它也有自动垃圾回收。这些都让它很适合做这个工作。而且，它跟 JavaScript 的相似性，也能让团队更容易理解和处理代码。
| 语言 | 团队没选它的原因 |
| Rust | 不支持循环数据结构，没有自动垃圾回收 |
| C# | （原文未明确，但未被最终选中） |
| Go | 语法和设计思路与 JavaScript 高度相似，有自动垃圾回收 |
用 AI 做编译器移植？现实并不理想
谈到 AI，Hejlsberg 的态度很冷静。他觉得现在的大模型，就像一个“高级复读机”。它们只是重复别人做过的事情。然后在此基础上做一些简单的推演。
团队最初也想用 AI 来移植代码。就是把 TypeScript 代码变成 Go 代码。但是效果很不好。
代码移植需要非常精确。团队要移植五十万行代码。而且新旧代码的运行逻辑必须完全一样。但是，AI 在翻译代码时容易出错。它会产生“幻觉”。“幻觉”就是 AI 自己编造了一些内容。或者它理解错了代码的意思。哪怕错一点点，你也要一行一行去检查。这样就太花时间了。反而更慢。
这就像微软的 Visual Studio 升级工具。以前的 .NET 升级助手很确定。它升级的东西不会出错。但是后来微软换成了基于 Copilot 的工具。这个新工具的输出就不确定。很多开发者抱怨它不好用。因为你不知道它会改出什么问题来。
Hejlsberg 认为，AI 应该这样用：让 AI 生成辅助移植的工具程序。这是它的工作原理：
- 先不让 AI 直接翻译代码。
- 然后，让 AI 帮你写一些工具程序。
- 这些工具程序再去执行代码迁移。
- 这样，工具程序就能输出确定的结果。
这样可以帮你更快完成移植工作。它不是直接帮你写代码，而是帮你造工具。
而且，他也认可 AI 的其他用处。比如，TypeScript 的语言服务。语言服务就是帮你检查代码语法。它还能给你修复建议。在这个地方，AI 就能做得非常好。它能比人做得更高效。
而且，团队也找到了 AI 的一个好用之处。他们完成了第一次大批量的代码迁移。之后，旧代码库里有新的改动。他们需要把这些新的改动也移植到 Go 代码库。在这个增量迁移的工作中，AI 的效果就很好。
TypeScript 的未来：语言不会激进更新，但工具链会彻底改变
谈到 TypeScript 的未来，Hejlsberg 说，它会继续走老路子。它会先跟着 JavaScript 的标准走。然后在 JavaScript 的基础上，加上需要的类型系统特性。
TypeScript 是 JavaScript 的“超集”。这意味着它扩展了 JavaScript 的功能。而且，TypeScript 的发展也会反过来影响 JavaScript 的标准制定。所以，大家不要期待 TypeScript 语言本身会有很大的变化。
Hejlsberg 认为，TypeScript 未来最大的变化会发生在工具链上。工具链就是我们用来写代码、编译代码的工具。
他说：“我以前觉得 IDE（集成开发环境）已经是最好的工具了。但是 AI 的出现，改变了这一切。” 他觉得现在 AI 不再只是 IDE 里的一个功能。它变成了开发者要监督的核心工具。甚至以后可能都“不需要传统的 IDE”了。
这是它的工作原理：
- 以前，IDE 是我们写代码的主战场。 我们在里面编辑、编译、调试。
- 现在，AI 会变得更聪明。 它会像一个助手一样。但是这个助手会更深入。
- AI 会直接理解代码的意思和结构。 它能直接提出修改建议。
- 这些 AI 工具需要语言服务的底层支持。 语言服务就像 AI 的眼睛和大脑。它让 AI 知道代码是什么。
- AI 会以大语言模型（LLM）或智能代理（Agent）的方式来工作。 它能做 IDE 能做的事情。
这样可以帮你更快完成开发。这意味着我们以后写代码的方式会完全不一样。我们可能更多是和 AI 沟通。让它来完成一些重复或者复杂的工作。
TypeScript 的诞生：不是为了“发明一门新语言”，而是为了修复 JavaScript 的痛点而生
最后，Hejlsberg 还讲了 TypeScript 是怎么来的。这个故事很有趣。
最开始的想法，来自微软的 Outlook Web 团队。这个团队当时用一个叫 Script# 的工具。他们用 C# 写代码。然后把 C# 代码编译成 JavaScript 代码。这样就能在浏览器里运行。
Hejlsberg 觉得这个想法很好。但是他没有直接基于 C# 来做。他决定做一个 JavaScript 的类型化超集。他的核心想法是：“我们扩展 JavaScript 的能力。我们不是想创造一门新语言。我们只是想解决 JavaScript 自己的问题。”
当时 JavaScript 有很多痛点。比如，项目大了以后，代码就很难管理。因为 JavaScript 是动态类型的。你不知道变量到底是什么类型。这很容易出错。而且，团队协作的时候也容易出问题。
所以，TypeScript 的出现，就是为了解决这些问题。它给 JavaScript 加上了类型。这样代码就更清晰了。更容易维护了。
现在，TypeScript 已经是非常流行的编程语言了。但是，微软把它的编译器从 TypeScript 迁移到 Go。这件事也说明了一个问题。就是 TypeScript 在性能方面，有它的极限。
RedMonk 的分析师 Stephen O’Grady 去年问过一个问题。他说：“如果一门语言连自己的编译器都跑不动了，这会不会影响人们对它的看法？”
这个问题提得很好。它让我们思考。TypeScript 已经很成功了。但是它未来怎么发展？怎么突破自己的极限？这些都需要时间来给出答案。
