Anders Hejlsberg ( @ahejlsberg ) is the creator of TypeScript and C#, and I asked him about how the TypeScript compiler got 10x faster through a rewrite in Go and his thoughts on how AI has impacted software engineering.

In this episode:

• How rewriting the compiler makes it 10x faster • Why they picked Go instead of Rust • Why they didn’t use LLMs for the migration • Predictions on AI’s impact on software engineering

Where to watch:

• YouTube - https://youtube.com/watch?v=cywK3XYYJ2o… • Spotify - https://open.spotify.com/episode/1thvWd3ClYQHvaUX9qKckk?si=pmojE4jTSPmHVnm4fydbFg… • Apple Podcasts - https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835… • Transcript - https://developing.dev/p/creator-of-typescript-10x-faster…

Thank you to the sponsors of this episode for supporting my work:

• WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com • Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at https://jira.dev

Chapters:

00:00 Intro 00:48 Why write a compiler in JavaScript 07:29 Why rewrite the compiler in Go 14:49 LLMs for large migrations 20:12 Why Javascript is so popular 26:32 Why ever use Javascript on the backend 32:59 What it takes to build a programming language 37:06 Will there be fewer languages in 10 years 42:57 Hands on engineering vs delegation 49:14 Why fast tooling matters more now 51:16 AI software engineering predictions 58:52 The most technically challenging work 01:02:04 Top book recommendation 01:03:50 Advice for his younger self 01:05:00 Outro

TypeScript编译器迁移至Go：性能、并发与语言选择

TL;DR： Anders Hejlsberg 解释了 TypeScript 编译器从 JavaScript 迁移到 Go 的核心原因——追求性能与共享内存并发，并详述了选择 Go 而非 Rust 的考量以及项目中有限度的 LLM 应用。

初始选择：为何用 JavaScript 编写 TypeScript 编译器

TypeScript 最初的原型（早期代号 Strata）是用 C 编写的，改编自 IE 的 JavaScript 解析器。但项目团队最终决定用 JavaScript 来重写编译器，这一决策基于几个关键优势：

1. 生态内自举：在希望融入的生态系统内实现自托管，比从外部针对它进行开发更有优势。团队每天都在使用自己构建的 TypeScript 工具链，这使得问题发现和性能优化更为直接。
2. 全平台运行：JavaScript 可以在任何地方运行，包括浏览器。这使得 TypeScript 编译器能够自动支持所有平台，而在当时（WebAssembly 普及之前），原生代码编译器无法在浏览器中运行。
3. 运行时性能：当时 JavaScript 的性能（通过 V8 引擎等）已接近原生代码两三倍之内。Anders 指出，编译器的性能往往由算法决定，而不仅仅是运行时环境。

原生重写的动因：性能与可扩展性瓶颈

尽管有上述优势，TypeScript 团队最终决定用原生代码重写编译器，旨在解决 JavaScript 环境带来的根本性限制：

1. 性能差距：JavaScript 从未为编译器这类计算密集型负载优化，它更适用于 UI 开发。与原生代码相比，JavaScript 存在约 2-3 倍的性能损失。
2. 并发限制：JavaScript 设计上是单线程的。虽然有 Web Workers，但它们之间无法共享内存，只能通过消息传递（如 JSON 序列化）通信。这意味着无法有效利用现代多核 CPU 的并行计算能力。随着摩尔定律转向核心数量的增加，无法利用多核成为严重瓶颈。

语言选择：为何是 Go？

团队评估了多种语言，最终选择 Go 进行移植，原因如下：

• 移植而非重写：目标是保留现有 TypeScript 编译器的精确语义和算法，以确保向后兼容。这要求新语言必须匹配原 JavaScript 代码库的关键假设。
• Go 符合核心需求：
  • 垃圾回收：原代码库假设存在垃圾回收机制，且依赖循环数据结构和闭包。Go 原生支持垃圾回收和这类数据结构。
  • 共享内存并发：Go 提供了优秀的、内置的共享内存并发（goroutines 和 channels），能直接利用多核 CPU。
  • 原生编译与跨平台：Go 能在所有主流平台生成健壮的原生代码。

对比 Rust 的不足：Rust 虽是系统级语言，但对该项目而言有两个关键缺点：

1. 内存管理模型：Rust 使用所有权和借用检查器手动管理内存，这不允许循环引用，而 TypeScript 编译器中充满循环数据结构（如带父指针的树、相互引用的符号）。
2. 无显著收益：在生成代码质量或并发收益上，Rust 相对于 Go 并没有明显优势，但采用 Rust 会引入更大的移植工作量和复杂性。

TypeScript 编译器的独特性

TypeScript 编译器（transpiler）与传统的原生编译器（如 Clang）有几个根本不同：

1. 输出目标：它生成 JavaScript 或 ECMAScript，而非机器码。
2. 核心任务：其编译阶段主要是移除类型注解，将 TypeScript 还原为 JavaScript。早期的“向下转换”（将新语法如 class 转换为旧版兼容的构造函数）因环境版本统一已不再重要。
3. 类型检查的目的：TypeScript 的类型检查纯粹为开发者工具链服务（代码补全、重构、导航），类型信息在运行时会被完全擦除，对代码行为无影响。
4. 渐进式类型系统：它允许部分代码有类型、部分为 any 且不进行检查，这是其独特的语言特性。
5. 优化重点：与优化运行时代码性能的传统编译器不同，TypeScript 编译器的“优化”旨在提升开发者或 AI 的开发效率。

移植过程与 AI 的应用

TypeScript 到 Go 的移植项目已进行两年。过程结合了手工、自动化和少量 AI 辅助：

• 手工编写核心组件：扫描器（scanner）和解析器（parser）是手工重写的。
• 自动化翻译工具：团队编写了一个在语法层将 TypeScript 翻译成 Go 的工具。生成的 Go 代码虽有语法错误且无法编译（因为类型处理方式不同），但提供了相同的代码结构基础，后续再进行重构和数据结构调整。
• 有限度的 AI 辅助：由于项目启动时 LLM 能力有限，AI 只在局部范围内偶尔用于帮助转换代码。Anders 认为，直接让 AI 翻译 50 万到 100 万行代码并不可靠，可能仍需人工逐行检查以防止“幻觉”。他建议，更有效的方法是让 AI 编写一个确定性的转换程序，将随机性控制在程序内。

结语

TypeScript 编译器迁移到 Go 的决策，是追求更高运行时性能、利用现代硬件多核能力，同时保持向后兼容性的务实选择。这一过程体现了语言选型在工程项目中的权衡——Go 在垃圾回收、原生并发和开发效率上的综合优势，使其成为此次特定移植任务的理想目标。

Source: https://www.youtube.com/watch?v=cywK3XYYJ2o