TypeScript 为什么重写原生编译器，以及这对 AI 编程意味着什么

这是个好问题。坦白说，如果在 TypeScript 项目开始前有人对我说“Anders，你要用 JavaScript 写编译器”，我会拒绝。TypeScript 最早的原型——早期叫 Strata 项目——其实是用 C 写的，改编自我们在 IE 里的 JavaScript 解析器，后来才转到 JavaScript，但写法仍偏 C 风格。为什么选 JavaScript？如果你能在自己想融入的生态里自举，那远好过站在生态外面去瞄准它。用 TypeScript 写，我们自己就是 TypeScript 和工具链的日常用户，哪里不对、哪里性能不行，我们立刻就知道，早期这是巨大的红利。而且 JavaScript 无处不在，编译器因此能自动跑在所有平台、甚至浏览器里——当时的原生方案做不到这一点，WebAssembly 那时还不存在。另外当时人们没意识到 JavaScript 已经变快了：Google 用 V8 把它带到原生代码两到三倍性能以内，相当了不起。用 JavaScript 写出高性能编译器完全可行，因为决定性能的往往是算法，而不一定是运行时环境。

TypeScript 编译器有几处相当独特。首先它不以机器代码为目标，而是以 JavaScript 为目标——有人称之为转译器，某种意义上编译阶段主要就是移除类型注解、把 TypeScript 还原回 JavaScript。早期编译流程还有个重要部分是降级处理：当时的运行环境并非常青，有的落后标准好几年。比如类标准化后多数 JavaScript 运行时并不支持，但可以降级为构造函数并做代码转换。再就是类型检查这个重头戏。TypeScript 的类型检查器与其他编译器里的很不一样：通常类型检查器是为代码生成器服务的，而我们擦除类型，类型对代码的运行时行为毫无影响，纯粹为工具和开发者服务——语句补全、重构、代码导航。TypeScript 还是渐进类型系统：一半代码可以有类型，另一半就是 any，极少有语言具备这种设计。这让这份工作非常迷人，因为我们解决的是前人没解决过的问题。

我们要解决的问题很简单：性能与可扩展性。JavaScript 从未真正为编译器这类计算密集型负载优化过——它更偏向浏览器里运行的 UI。首先，用 JavaScript 做计算，相比原生代码要付出两到三倍的性能代价，具体取决于负载，但计算密集型大致就是这个水平。其次，它对并发的使用限制很多。JavaScript 一直被设计成单线程语言——这正是回调和 async 存在的原因：你开不了线程。这多半是好事，因为在有可变数据的语言里并发非常难：竞态、死锁这些问题都会出现。函数式编程语言的并发更容易，因为数据都不可变。JavaScript 除 Web Worker 外不提供并发，而 Worker 之间无法共享数据，只能序列化传递——一个 Worker 算好的数据要给另一个用，得先转成 JSON。换句话说，没有共享内存并发，而这正是我们想利用当今人人皆有的多核 CPU 所需要的。摩尔定律不再给我们更快的 CPU，而是给我们更多的 CPU，我们在多个方面都在白白浪费机会。所以我们要找一门能同时解开这两个结的语言：它必须是原生的，且必须能访问共享内存并发。