Anders Hejlsberg 亲自下场把 TypeScript

看完最新那期访谈，最大的感受是：TS 团队终于不装了，直接把 tsc 整个移植到 Go，目标是编译速度提升 10 倍。以前靠 --projectReferences 拆项目、用 esbuild/swc 绕着跑，本质上还是在 JS 单线程 + GC 压力里挣扎。现在原生二进制启动快、内存占用低、并行处理没锁竞争，架构层面的天花板直接打穿了。

一、为啥偏偏是 Go？

Rust 虽强，但团队熟悉度、GC 成熟度、跨平台分发的便利性，Go 对于一个要维护十几年的核心基建项目来说，性价比最高。Hejlsberg 直说：“我们不想在内存管理上烧脑，要把精力花在类型系统逻辑上。” 这波 pragmatic（务实）劲儿，很像当年来 C# 设计时的风格。

新架构大概长这样：

• 前端：Go 实现的 parser / binder / checker，输出 IR
• 后端：复用现有 JS 发射逻辑（或逐步迁移）
• 增量编译：基于文件系统监听 + 依赖图，毫秒级响应

二、关于「AI 不会取代程序员」那段话

Hejlsberg 的观点很硬核：AI 写代码像「实习生提 PR」，你还是得做 Code Review、架构决策、边界条件兜底。 类型系统的价值反而上升了——有了强类型，LLM 生成的代码才能被静态分析、重构工具安全托管。他甚至半开玩笑说：「未来最稀缺的不是写代码的手，而是能精准描述意图、验证正确性的脑子。」

三、我关心的落地细节

1. 迁移节奏：官方说「非破坏性」，但插件生态（ts-loader、fork-ts-checker-webpack-plugin 等）得跟进原生 API，短期内大概率双版本并存。
2. 类型系统兼容性：Go 版 checker 能 100% 复现现有行为吗？特别是 conditional types、inference edge cases，回归测试量级极大。
3. Windows ARM / Linux musl：原生二进制分发能不能别再踩 glibc 版本的坑？

---

想亲自跑跑 benchmark 的，可以关注 typescript-go 仓库（目前还在 internal 阶段），等 Public Preview 再拉下来 go build 试试水。毕竟 「编译器快 10 倍，CI 账单省 90%」 这诱惑力，没几个前端基建能顶得住。