TypeScript 之父 Anders Hejlsberg：别折腾“AI 新语言”了，真正变天是 IDE 让位给 Agent
过去十年，TypeScript 被很多团队当作“工程化 JavaScript”的答案；到了 AI 编程时代，它又意外变成了 AI 最顺手的语言之一——原因很简单：AI 写代码的能力基本取决于它见过多少这种语言的代码，而 TypeScript/JavaScript 恰好是训练语料最丰富的那一档；更关键的是，TypeScript 还把类型与接口这些“语义线索”明明白白写在代码里，正好让 AI 更容易理解、重构和补全。 也正是在这种背景下，微软在 2025 年 12 月 16 日完成了 TypeScript 史上最激进的一次重构：用 Go 语言迁移（重写）编译器与部分工具链，宣称带来 10 倍性能飞跃。但消息一出，社区立刻炸锅——明明 Rust 才是当下重写系统级工具的“默认答案”，为什么偏偏选 Go？ TypeScript 之父、同时也是 Turbo Pascal、Delphi、C# 等语言的核心设计者 Anders Hejlsberg，在与 GitHub 研究顾问 Eirini Kalliamvakou 的对谈中正面回应了这些质疑：很多人认为他们“应该选另一门语言”，但他坚持“我们选了最合适的工具，而且过去一年已经证明了这一点”。 更有意思的是，Hejlsberg 也谈到 AI 在这次迁移中的真实位置：团队曾尝试让 AI 直接把 TypeScript 代码迁移到 Go，“结果不太理想”，因为他们需要的是五十万行代码级别、行为完全一致的确定性迁移；AI 只要偶尔“偏一点”，就会把成本转移到逐行审查上，得不偿失。相比之下，让 AI 去生成迁移工具、以及在迁移之后自动同步旧代码库新增的 PR 变更，反而更有效——这部分他们“已经相当成功”。 同时，Hejlsberg 也明确指出：在“AI 无处不在”的新环境里，TypeScript 的语言服务（补全、跳转、重构、快速修复）不会只是原样搬家，而是在被大幅重塑——因为很多过去必须靠 IDE 才能做的事，AI 将会做得更好。未来真正不确定的也不是 TypeScript 语言本身（它仍沿着 JavaScript 标准化路径演进），而是工具形态：AI 正从 IDE 的助手变成主要工作者，人类转向监督与审阅；这也是为什么把语言服务接入 MCP 这类机制会突然变得诱人——让 AI 能提出语义级问题、发起重构请求，用“智能体方式”完成过去只能在 IDE 里完成的工作流，开发工具将因此被彻底改写。 基于该播客视频，InfoQ 进行了部分删改。 核心观点如下： 通过扩展 JavaScript 的能力，我们并非要创造一门全新的语言，而只是想修复它本身存在的问题。 对 AI 来说，“最好的语言”就是它已经大量见过的语言，在这个新世界里，全新的编程语言反而处于劣势。 找到那些无聊却昂贵的事情，把它们交给 AI。 工程师的金字塔正在变窄，入门层级的人变少了，而我们需要认真思考，如何在这样的环境下培养下一代资深工程师。 开源本身是一场巨大的实验，尽管至今没人真正解决“如何为开源持续提供资金”这个问题，但它不仅没有衰退，反而比以往任何时候都更庞大、更活跃。 Eirini：从 Turbo Pascal、Delphi、C# 到如今的 TypeScript，你的工作塑造了数以百万计开发者每天写代码的方式。 Anders：我第一次接触计算机大概是在高中时期，那是 70 年代末，我很快对编程产生了浓厚兴趣。后来，随着 8 位微型计算机开始出现，我决定自己动手组装一台套件机，并为它编写大量软件。我发现自己在这方面做得相当不错，而且也真的很享受这个过程。那时无论是结构化编程还是汇编语言，对我来说都不成问题。当然，还要考虑一个现实条件：只有 64K 内存，能塞进去的东西非常有限，还得给用户留出空间，所以当时一切都还能装在脑子里。 Eirini：Turbo Pascal 在很大程度上革新了开发者体验，核心在于缩短开发者的反馈回路。这在多大程度上是你一开始就有意识的设计理念？ Anders：首先，人们之所以喜欢早期机器上的 BASIC，很大原因正是它的短反馈周期。BASIC 是解释型语言，输入代码就能立刻运行，但代价是运行速度慢，而且编辑器是基于行的，体验很糟。相比之下，当时的文字处理软件已经是所见即所得的屏幕编辑器，可以自由移动光标，这显然更适合写代码。与此同时，“输入—运行—立刻看到结果”的模式又非常吸引人。 要在编译型语言中实现这一点并获得性能，就必须有极快的编译器。Turbo Pascal 的做法是：你一按下运行，它立即在内存中完成编译，甚至不需要访问磁盘，然后直接运行。如果出现错误，就立刻回到编辑器。编译器本身非常原始，你甚至需要通过出错地址反推源码位置。但正因如此，突然之间就获得了一种高度交互的体验，在当时堪称革命性。 Eirini：那种“编译要等一个下午”的体验，会不会让你感到沮丧？ Anders：当然会，没有人喜欢等待。代码已经写完了，你只想立刻运行，而不是坐在那里干等。 Eirini：Turbo Pascal 还有一个重要影响，就是以低价让更多人接触到编程。回头看，这一点你有什么感受？ Anders：这里有个有意思的故事。Turbo Pascal 的前身叫 Poly Pascal，是我在丹麦一家小型软件公司里开发的 Pascal 编译器。后来我们联系上了 Borland 的创始团队，他们看过之后觉得非常惊艳，提议一起把它作为产品推向美国市场。然后他们决定定价 49.95 美元。我当时的反应是：“你们疯了吗？这样根本赚不到钱。”事后看来，这个决定非常聪明。虽然价格只有原来的十分之一，但销量却高出了三到四个数量级。最终结果非常成功，这个功劳主要要归于 Borland 的创始人 Philippe。 Eirini：Delphi 标志着你从独立创作者向团队领导者的转变。 Anders：一开始我基本上是单打独斗，虽然在丹麦的 Borland 办公室也会和两三个人合作，但随着机器性能飞速提升、用户期望不断提高，这种模式显然无法持续。我必须学会团队协作，这在 Turbo Pascal 期间就已经开始，而在 Delphi 项目中尤为明显。 你必须接受事情不会完全按照你个人偏好的方式完成，代码也不一定长成你心目中的样子。而且你往往没有时间亲自去“修正”这些细节，何况那样做也未必真的改变产品行为，更重要的是学会放权。只有当团队成员在各自负责的功能和模块中感到被信任、被赋权，团队才能真正运转起来。 Eirini：你在 Microsoft 参与 Visual J++ 的经历，对 C# 和 .NET 平台的目标产生了怎样的影响？ Anders：我是在 1996 年底加入 Microsoft 的，担任 Java 开发工具集的首席架构师。我们刚发布了 Visual J++ 1，本质上只是把 C++ 的 IDE 换成 Java 编译器，谈不上真正的集成，更没有快速的应用开发体验。于是我们着手改进，这最终成为 Visual J++ 6.0，并开始与 Visual Basic、Visual Studio 的版本体系对齐。 如果要为 Microsoft 的 DOS 和 Windows 平台做 Java，就必须与这些环境高度互操作。但 Java 当时强调“一次编写，到处运行”，强制使用最小公分母的 UI 接口，最终只能做出体验很差的小程序。我们不得不引入一些扩展，简化与原生平台的互操作，并构建封装 Windows UI 的类库。很快就发现，这条路走不通。 如果真正为用户着想，就必须允许构建针对特定环境的最佳方案。人们既想要 Visual Basic 的易用性，又想要 C++ 的表达能力。于是我们尝试把这两者结合起来，并构建在 .NET 这样一个可持续演进的平台之上，最大限度地利用用户所运行的系统能力，这正是整个构想的核心。 Eirini：你既在谈不同类型的用户，又在描述为整个生态系统服务的思路，这种整体视角是如何形成的？ Anders：用户并不在乎这是语言特性、框架特性、平台能力，还是编辑器或调试器的问题，对他们来说，一切加在一起才是“体验”。因此，这些部分必须协同设计。 我们构建了运行时、JIT 编译器、垃圾回收器，设计了平台的字节码，开发了类库。我既参与语言设计，也参与类库和运行时的设计，与负责这些组件的工程师密切合作，最终效果因此更好。否则，各自为政会形成孤岛，最后只能靠复杂的互操作层勉强拼接，结果自然谈不上“最佳实践”。 此外，我们也不惧怕与底层平台深度互操作。过于教条地坚持最小公分母，拒绝利用具体平台的优势，这样永远不可能做到真正意义上的“最佳体验”。 Eirini：当时是否有某个“顿悟时刻”，让你意识到 JavaScript 在规模化发展中的阵痛已经成为必须解决的问题，而且这是一个需要由你、由 Microsoft 来解决的问题？ Anders：行业里的运行时环境开始变得足够成熟，比如 Google 在 V8 上做了非常出色的工作，JavaScript 的运行性能突然变得相当可观。HTML5 也正式定稿，UI 能力大幅提升。同时，手机、iPad 等各种形态的设备出现了，而它们并不运行 Windows。整个行业突然意识到，真正的平台竞争不在 Java，而在 JavaScript、浏览器和 HTML 上。 于是，人们开始编写越来越庞大的应用，因为新的运行时和 UI 技术已经允许这样做。但很快大家就发现，在一种动态语言里、缺乏成熟工具支持的情况下，这件事难得令人发指，于是我们看到了各种奇怪的扭曲做法。 其中一个典型案例是 Outlook.com 团队找到我们，主要是 .NET 和 C# 团队，询问是否可以把他们内部的一个叫 Script# 的东西产品化。我当时一头雾水：“Script# 是什么？”他们说，这是一个允许你用 C# 编写代码，然后编译成 JavaScript 来运行的工具。我第一反应是：这听起来像是两边的缺点都占全了。 但事实是，这么做的真正原因在于可以获得“成熟的工具链”：类型检查、团队协作能力、接口定义，以及对模块之间交互方式的清晰描述。因为他们有成百上千名程序员参与开发，不可能只靠裸写 JavaScript，在没有检查、没有自动补全、没有重构支持的情况下完成工作。 这让我开始反思：JavaScript 真的已经糟糕到这种程度了吗？而“先写另一门语言，再把 JavaScript 当成中间表示或字节码来编译”，真的是解决问题的最佳方式吗？如果能直接修复 JavaScript 本身，会发生什么？于是我们开始探索这条路，事实证明，这个方向效果相当不错。 Eirini：TypeScript 被设计成 JavaScript 的严格超集，这背后显然有深思熟虑的战略考量。你是如何坚持这一决策的？这又能给其他语言设计者哪些启示？ Anders：每当有人跑来跟我说：“我在考虑做一门全新的编程语言，能解决这个、解决那个”，我给出的第一条建议通常是：这个世界对新编程语言的需求，就像对头上再多一个洞的需求一样。 第二条建议是：如果你真的要做一门语言，要意识到其中 90% 的工作，和其他所有语言是完全一样的，而且这个比例还在不断上升。如今，程序员的期望早已不只是一个编译器，你还需要完善的语言服务，能够集成到几乎所有主流 IDE 中，需要能与 AI 交互的 MCP 服务器，需要调试器、性能分析工具…… 此外，你还得有至少十年的时间，因为一门语言真正站稳脚跟、获得有意义的用户规模，往往就是这么长的周期。没有人会在一开始就拥抱一门全新的语言，头五年你很可能用户寥寥，还得不断回答“我们真的要继续投入吗？”这是一门非常艰难的生意。 通过扩展 JavaScript 的能力，我们并非要创造一门全新的语言，而只是想修复它本身存在的问题。在 Visual Studio Code 里，我们的语言服务对 TypeScript 和 JavaScript 是同一套。对我们而言，JavaScript 只是没有类型注解的 TypeScript，或者使用 JSDoc 注解的另一种形式。这意味着我们不是在做两套东西，而是在同一项投入之上，精确地构建真正必要的能力，只为让整个生态系统变得更好。 Eirini：2012 年在 GitHub 上启动 TypeScript 的开源项目，在当时的 Microsoft 可以说是一次相当激进的举动。 Anders：我们当时对 JavaScript 生态的运作方式、价值观以及参与社区所需的前提，其实有着非常清晰的认识。大家都明白，如果不开源，这个社区根本不会理你，一个封闭的商业产品对他们毫无吸引力。因此，从一开始我们就主张开源。同时，Microsoft 内部也逐渐意识到，开源并不是“洪水猛兽”，而是如果想真正与开发者对话，就必须拥抱的现实。 你刚才提到 2012 年发布在 GitHub，其实并不准确。2012 年我们发布在 CodePlex——Microsoft 自家的、并不太受欢迎的开源平台上。结果就是，反响寥寥。那时所谓的“开源”，更多只是把代码丢到仓库里，让大家提 issue，然后我们再把这些 issue 抓回内部系统，按内部流程处理。某种程度上，这也解释了为什么几乎没人关注。 再加上当时 Microsoft 在开源社区中的信誉并不高。真正的“主战场”在 GitHub。于是 2014 年我们迁移到了 GitHub，全面采用开放式开发流程。内部成员和外部贡献者遵循完全相同的规则，所有功能都通过 Pull Request 提交，所有讨论都公开进行。直到那时，项目才真正开始起飞，社区的兴趣也随之而来。 Eirini：从“把代码扔给社区”到真正的开放式开发，你们学到了哪些经验？ Anders：这是一个彻头彻尾的双赢。对用户来说，他们能看到“香肠是怎么做出来的”，所有讨论都在公开的 issue 里完成，而不是私下做决定后再给出一个结果。 对项目开发者而言，这种方式同样令人满足。你每天都能感受到社区的参与和认可，看到点赞、看到讨论，远比关起门来做六个月或一年，然后祈祷产品方向正确要有趣得多。在这里，用户每天都在用投票告诉你他们最想要什么功能，我们只需按票数排序，就能清楚地知道优先级。你解决这些问题，社区的热情就会进一步增强，形成正向循环。 Eirini：把 TypeScript 编译器迁移到 Go 背后的动机、权衡以及所面临的挑战是什么？ Anders：TypeScript 从一开始就是自托管的，用它自身编写，这意味着编译器和整个工具链本质上都是一个 JavaScript 应用。这带来了很多好处，比如你甚至可以在浏览器里运行编译器，在浏览器中构建一个完整的 IDE，一切都能正常工作。但随着 TypeScript 的广泛采用，以及用户项目规模不断扩大，可扩展性逐渐成为头号问题。 这里有 JavaScript 本身的一些内在限制。它在设计上是单线程的，不支持共享内存并发，这意味着你实际上浪费了 90% 的计算能力。此外，JavaScript 的执行成本也很高，它的对象模型极为宽松，可以随意给对象加属性，这使得优化非常困难，底层往往演变成复杂的哈希查找和缓存机制，远不如原生代码高效。 所以我们当时就清楚，自己正接二连三地白白损失收益。尽管放弃自托管让人非常不舍，但即便用尽所有优化技巧，性能瓶颈依然无法突破。 于是，在 2024 年夏天，我们开始做原型验证，先从扫描器、解析器这些容易量化的模块入手。很快就发现，性能提升可以达到 10 倍：一半来自原生代码，一半来自共享内存并发。这样的提升能把原本需要几分钟的事情缩短到十几秒，完全改变了游戏规则。 同时，我们也很清楚不想从零重写一个全新的编译器。社区里有不少声音主张“用 Rust 全部重写”，但我们认为这并不可行。TypeScript 的类型检查器极其庞大复杂，许多行为只体现在现有代码的精确语义中。如果重写，就会陷入永无止境的差异追赶，最终无法与旧编译器对齐。 因此我们的目标是“迁移”，逐函数地把同样的逻辑搬到原生语言中。当然，这意味着必须重构数据结构，因为原生语言不允许像 JavaScript 那样随意给对象加属性。我们尝试过多种语言，很快排除了 Rust，因为我们的编译器充满了循环数据结构，并且高度依赖自动垃圾回收，使用 Rust 等同于重写。 最终我们选择了 Go。它在很多方面与 JavaScript 相似，这个选择对我们来说非常奏效。现在我们拥有了一个原生编译器，在功能上几乎是旧编译器的拷贝，连那些小怪癖都一模一样，只是快了 10 倍，这意味着社区不需要推倒重来。当我们正式切换时，我相信大家会非常满意。 Eirini：在 AI 辅助编程的背景下，你认为 TypeScript 为什么特别适合 AI 工作流？ Anders：很多人问我，为什么不干脆设计一门“最适合 AI 的完美编程语言”。我的回答通常是：那样的语言反而会成为最不适合 AI 的语言，因为它不会出现在 AI 的训练数据中。 AI 在某种语言中写代码的能力，与它见过这种语言代码的数量几乎成正比，它本质上是在大量样本的基础上进行再组合和外推。AI 已经见过海量的 JavaScript、Python 和 TypeScript，因此在这些语言上表现得非常好。对 AI 来说，“最好的语言”就是它已经大量见过的语言，在这个新世界里，全新的编程语言反而处于劣势。 AI 的确正在改变我们构建产品的方式。以这次 TypeScript 迁移为例，我们也尝试过用 AI 自动完成代码迁移，但效果并不好。一方面那是一年前的 AI，能力还有限；另一方面，迁移五十万行代码并保证行为与原代码完全一致，我们需要的是极其确定性的结果。AI 在翻译过程中可能会产生细微的“幻觉”，而你又不得不逐行检查，这并不划算。在这种情况下，更好的方式或许是让 AI 帮你生成“迁移工具”，而不是直接迁移代码。 TypeScript 项目中有很大一部分是语言服务，为 IDE 提供补全、跳转、重构和快速修复。现在我们也在思考：既然 AI 已经能在很多场景下做得更好，是否还有必要原样迁移这些功能？类型检查器我们完整迁移了，但语言服务正在被大幅度重塑，以适应一个“AI 已经无处不在”的新环境。 Eirini：你如何看待 AI 工具正在改变编程本身，以及语言设计的方式？ Anders：在理想状态下，AI 应该帮助我们消除编程中那些繁琐、重复的劳动。以 TypeScript 的迁移为例，在我们开发新代码库的同时，旧代码库里仍然不断有新的 Pull Request 出现，我们已经相当成功地用 AI 把这些变更迁移过来。 再比如，项目里有成千上万条 issue，其中很多非常古老。它们是否仍然可复现？是否还相关？能否根据社区反馈排序？这些清理和维护工作过去总是被一拖再拖，最终却成为拖慢项目前进的“锚”。现在，我们可以构建 AI 机器人来完成这些工作。这是我认为非常重要的一点：找到那些无聊却昂贵的事情，把它们交给 AI。 当然，这也带来新的困惑。如果 AI 取代了初级工程师，我们又该如何培养资深工程师？难道指望 AI 自己成长为“高级程序员”，而人类程序员逐渐消失吗？我并不这么认为。我们似乎正在逼近某种上限：AI 能做很多事，但仍然需要人类以某种监督者的角色参与其中。 可以预见的是，工程师的金字塔正在变窄，入门层级的人变少了，而我们需要认真思考，如何在这样的环境下培养下一代资深工程师。 Eirini：如果把时间拉长到未来五到十年，在一个更加 AI 原生的世界里，你认为 TypeScript 作为一门编程语言会如何演进？ Anders：我认为它的演进方向其实相当清晰。JavaScript 已经不再是一门年轻的语言，它有一套成熟的标准化流程，而我们也深度参与其中。TypeScript 会沿着 JavaScript 的标准化路径继续发展，同时在其之上补充必要的类型系统能力。 真正充满不确定性的，是工具层面的变化。谁能想到，随着“对话式编程”这类形态的出现，命令行工具又重新变得如此重要？过去，AI 更多是作为助手存在：开发者在 IDE 里，AI 帮你更快地输入和补全代码。但现在，这种关系正在反转。AI 开始承担主要工作，而人类转向监督和审阅。此时，AI 并不一定需要我们传统意义上的 IDE，尽管它仍然需要语言服务。 这也是为什么 MCP 这类技术开始变得有吸引力：通过把语言服务接入 MCP，让 AI 能够提出语义级的问题、重构请求等，并在一定的确定性边界内完成工作流。这本质上是在用 LLM 或 Agent 的方式，完成过去只能在 IDE 中完成的事情，这将深刻改变开发工具的形态。 Eirini：围绕 TypeScript 或你们的工作，有没有哪些你希望公开澄清的误解？或者哪些你觉得被社区忽视、但其实很重要的事情？ Anders：在开源领域，我们与社区的距离非常近。如果哪里不对劲、存在摩擦，几乎会第一时间被反馈出来。比如这次转向原生代码的决定，确实引发了不少争议，有人认为我们应该选择另一种编程语言。但我始终坚信，我们为这个目标选对了工具。过去一年里，这个决定的成果已经逐步显现。 不过，开源本身就是一种微妙的平衡。一方面，你在无偿地把成果交给世界；另一方面，这个项目往往由一家商业公司资助，而公司必须以某种方式生存下去。总得有人支付账单。因此，我们团队始终处在一种张力之中：如何让开源项目既符合社区期待，又与公司使命保持一致。这并不是 TypeScript 独有的问题，而是当今几乎所有开源项目都面临的现实。至于是否存在一种更好的激励机制来回馈长期投入的人，目前还没有答案。 Eirini：开源的可持续性，确实是一个反复被提起的问题。 Anders：大量企业的正常运转，事实上依赖于那些支撑其后端的开源项目得到持续维护。但现实中，很多人对开源的态度仍然是“索取多于付出”。在微软，我们至少在努力以一种更真诚的方式参与其中。仅 TypeScript 项目，就已经累计投入了数百人数年的工作量；而 Visual Studio Code，投入甚至可能达到上千人。 Eirini：如果不算你自己参与创造的语言，你最敬佩、最尊重哪一门编程语言？ Anders：任何一门能被程序员广泛使用、甚至能进入讨论范围的编程语言，都一定有其可取之处，因此都值得尊重，我深知一门语言要走到这一步有多难。 以 Rust 为例，我非常敬佩它通过借用检查器来探索一种不同的内存管理方式，试图在不依赖昂贵自动垃圾回收的情况下保证安全性。我也很尊重 Go，尽管它在设计上有些“怪”，常被认为不太正统，但它实际上提供了一种简单、内存安全、类型安全的“现代 C”的思路。至于 Python，它的成功不需要多说，它驱动着 AI 和机器学习的发展，令人难以不心生敬意。 从语言设计者的角度看，我们都站在前人的肩膀之上。如果设计一门语言却不向其他语言学习，那是愚蠢的。经验与智慧就在那里，理应被尊重和继承。 Eirini：当你放眼整个以 GitHub 等协作平台为中心的软件开发生态时，是什么让你对未来保持乐观？ Anders：仅仅是它依然存在这一事实，就足以让我感到乐观。开源本身是一场巨大的实验，尽管至今没人真正解决“如何为开源持续提供资金”这个问题，但它不仅没有衰退，反而比以往任何时候都更庞大、更活跃。 当然，其中也有大量噪音，有不少项目缺乏维护，但不可否认的是，这些代码记录了软件演化的全过程。以我们为例，转向这种协作工作流后，十二年的历史都被完整地保存在那里，可搜索、可追溯。如果我记得某个问题曾被讨论过，只需要去查找，而不必面对一封再也找不到的旧邮件，这种价值是巨大的。正因如此，我由衷地高兴看到它仍在持续增长，并顽强地存活下来。 参考链接：不如直接修 JS：TypeScript 的顿悟时刻
JavaScript 单线程的天花板：我们在浪费 90% 的算力
“最适合 AI 的语言”
