一个人，40年，打造4门爆款语言！实用主义，才是编程语言真正的护城河

今天聊一个技术圈悬了四十年的谜题。

1983年，一个丹麦程序员和他的小团队开发了一款 Pascal 编译器。当时市面上的编译器普遍定价在 500 美元上下，编译一次代码需要十几分钟，编辑器和编译器是分开的两个程序——你先在编辑器里写好代码，退出去跑编译器，等半天出结果，出了错再回到编辑器里改，周而复始。

这个丹麦团队的编译器定价多少？

49.95 美元。

没有打折，没有促销——正价，49.95 美元，同行的十分之一。

更离谱的是体验。他们在程序里做了一个“Run”按钮，按下去的一瞬间，编译器直接把代码编译进内存、立刻执行——不写磁盘，不等IO，编译完直接跑。出了错？自动跳回编辑器，光标停在出错的那一行。

这是一个前所未有的东西：你写代码，按一下按钮，它就跑了。

这款产品叫 Turbo Pascal。

后面发生的事情，教科书上已经写得很清楚了。Turbo Pascal 没有靠低价的十分之一卖出十分之一的利润——它靠低价的十分之一卖出了三到四个数量级以上的拷贝，把一个只有专业工程师才买得起的工具，变成了高中生攒攒零花钱就能入手的东西。

而那个丹麦程序员，叫 Anders Hejlsberg。

后面四十年里，他又做了三件事：Delphi、C#、TypeScript，加上 Turbo Pascal，这四个产品横跨了个人计算机、客户端/服务器、企业级开发和互联网四个时代，每一次都在一个截然不同的技术范式里拿下了主流地位。

连续四次，换了四张完全不同的牌桌，同一个人，全赢了。

这不是运气，四十年里同一个人连续赌对四次，概率论上就不支持“运气”这个解释。

一定有一套底层逻辑，Hejlsberg 在反复使用。而把这四次决策摊开来一一拆解，这套逻辑的轮廓会变得非常清晰。

Turbo Pascal：把“等”字从编程词典里删掉

很多人以为 Turbo Pascal 的成功是低价策略——便宜当然重要，但便宜解释不了全部，如果只是便宜，市面上后来会出现更便宜的克隆品把它卷死，事实上并没有。

真正的杀招，藏在 Hejlsberg 对“编辑-编译-运行”这个循环的重新设计里。

在 Turbo Pascal 出现之前，编程是这个样子的：你在一个简陋的行编辑器里写代码（对，行编辑器，不是全屏编辑器，一次只能看到一行），写完退出，运行编译器，编译器读磁盘上的源文件，吭哧吭哧编译，输出结果。如果有错，你得记住错误在哪一行，回到编辑器里找到那个位置，修改，再退出，再编译，再等。

Hejlsberg 当时的想法是：文字处理软件早就有全屏编辑器了，可以在屏幕上任意移动光标编辑文本，为什么写代码不能用这种东西？而编译这件事——如果用户的直觉是按一个按钮就应该跑起来，而编译器的性能又足够快，为什么不能把编译做成瞬间完成、用户根本感知不到的事？

来算一笔账。在 Turbo Pascal 之前，一个程序员从写完一段代码到看到运行结果，中间经过的步骤是：退出编辑器 → 运行编译器 → 等待磁盘IO → 等编译完成 → 运行程序 → 出错 → 记住行号 → 重新打开编辑器 → 找到那行。这个循环跑一趟，几分钟打底，一天跑几十趟，几个小时就这么没了。

Turbo Pascal 把这个循环压缩到了：按 Run → 内存编译（毫秒级）→ 出错自动跳编辑器，循环时间从几分钟变成了几秒。

发现没有？Hejlsberg 做的事情，在编译器学术圈看来完全是歪门邪道——他重新定义了程序员的时间预算，一个职业开发者一天的有效工作时间是固定的，你把编辑-编译-运行这个循环从 5 分钟砍到 5 秒，等于把一个人每天的“等”全部兑换成了“写”。一个程序员一天能多写多少代码、多试多少想法？

这才是 Turbo Pascal 真正的护城河：价格只是让用户进门的门票，循环时间才是让用户留下来不走的原因，同行在比谁生成的机器码跑得更快，Hejlsberg 在比谁让程序员等得更短——完全是两个维度的竞争。

有人可能要说了，这种“把工具做得快一点”的思路，谁不会啊？问题在于，在 1983 年，几乎没有人认为编译速度是一个值得优化的指标，编译器研究者们在比谁的优化更激进、谁生成的代码跑得更快、谁支持的语言特性更先进。编译速度？那是一个边缘指标，不值得发论文。

Hejlsberg 是那个把边缘指标变成核心卖点的人。而同样的剧情，在后面的三场战役里，他会一再重演。

Delphi 到 C#：当你的对手是用户已经拥有的东西

Turbo Pascal 之后，Hejlsberg 遇到了一个新的难题——不是技术上的。

随着产品越来越大，功能越来越多，他发现自己一个人写不过来了。“在 Turbo Pascal 的早期，我基本上是一个人的演出，”他在今年的一次访谈里回忆，“但机器的能力在急剧增长，用户期待也在急剧增长，你不可能一个人搞定所有事情。”

从个人开发者到团队领导，这个转变的核心锚点，在心理层面。“你得接受事情会以跟你偏好不同的方式完成，代码不会长得完全像你想要的那样。而且你也没时间去修正它——说实话，修正了也未必会改变产品的行为。”

这个表述，任何带过技术团队的人都能感受到分量，但 Hejlsberg 很快在 Delphi 项目里学会了更深的一课：团队协作的关键在于管住“授权”这件事，代码反而是次要的。“你不可能有一个团队，除非人们觉得自己被赋权了——在他们负责的功能领域、在他们构建的那部分产品里，他们有真正的决策权。”

Delphi 在 1995 年发布时，做到了一个在当时看来几乎不可能的组合：可视化快速开发 + 原生编译性能——你拖拽控件搭界面，点编译，出来的是原生机器码。这在当时是一个让所有人侧目的产品。

然后，1996 年底，Hejlsberg 被挖到了微软。

他的新任务是：做微软的 Java 开发工具。当时微软刚发布了 Visual J++ 1.0，本质上就是把 Visual C++ 的 IDE 里的 C++ 编译器拔掉，塞了一个 Java 编译器进去——能用，但完全没有“快速开发”的感觉。Hejlsberg 的团队开始往里面加料：更好的 Windows 互操作、把 Windows UI 封成类库、让 Java 调用 COM 组件……做着做着，他们发现了一个根本性的矛盾。

Java 的核心承诺是“一次编写，到处运行”，为了实现这个承诺，Java 只允许你使用它钦定的 UI 接口——也就是所有平台的最小公分母，结果就是用 Java 写出来的桌面程序，在哪个平台上都长得像一个外人。Windows 用户打开一个 Java 写的窗口，按钮不像 Windows 按钮，菜单不像 Windows 菜单，整个交互都是“陌生”的。

Hejlsberg 对此的评价非常直白：“你永远不可能用最小公分母的方式做出最好的产品。”

但微软的客户在乎的不是“一次编写到处运行”——他们用的是 Windows，他们想要的是在 Windows 上最好的体验。他们想要的，是把 Visual Basic 的易用性和 C++ 的表达力揉在一起的产物——这就是 C# 和 .NET 的起源。

回过头看，这个决策在当时被 Java 阵营视为“背叛”和“分裂”，但二十年后再看，Hejlsberg 的逻辑其实非常清晰——甚至可以说是不可反驳的：你的用户已经选择了一个平台，你就该为那个平台做到极致，你不能因为一个漂亮的跨平台承诺，就让用户接受一个在所有平台上都打折的体验。

换一个角度来算这笔账。Sun 的“一次编写到处运行”策略，本质上是在赌一个未来——赌所有平台最终会趋同，赌最小公分母最终会足够大。微软的策略是在赌现在——用户此刻正在用什么，就给什么做到最好。前者是理想主义者的长期期权，后者是实用主义者的当期现金。

编程语言的历史反复证明了一件事：当期现金的折现率，远远低于长期期权。

TypeScript：不要发明新语言，修好他们已经用的那个

2010 年前后，一个诡异的现象开始在微软内部出现。

http://Outlook.com 的团队跑来找 Hejlsberg，他们当时在用一种叫 Script# 的东西——一个把 C# 代码翻译成 JavaScript 的工具。Hejlsberg 的第一反应是：这什么玩意儿？把 C# 编译成 JavaScript 再跑？这听起来像是两个世界最糟糕的部分砸在了一起。

Outlook 团队的解释让他沉默了。

“我们有几百个、上千个程序员要同时在这个项目上工作。他们不能直接写 JavaScript——没有类型检查，没有接口，没有办法描述软件的各个部分如何互相通信，没有语句补全，没有重构工具。传统 IDE 能给你的东西，JavaScript 一样都给不了。”

Script# 的逻辑是：既然 JavaScript 没有这些东西，那就写 C#，然后把它翻译成 JavaScript——把 JS 当成一种“中间语言”来用。

Hejlsberg 当时脑子里想的是：“JavaScript 真的烂到这种程度了吗？真的最好的办法就是让所有人写另一种语言、把 JS 当编译目标？能不能直接修好 JavaScript 本身？”

这个问题的答案就是 TypeScript，但真正精彩的部分在“怎么修”这三个字上，当时市面上已经有几十种“编译到 JS”的语言了：CoffeeScript、Dart、ClojureScript……它们说的是同一句话：“JavaScript 太烂了，我们用一种更好的语言来替代它。”

TypeScript 说的是完全相反的一句话：不创造新语言，只在 JavaScript 上加类型标注。

// 这就是一个合法的 JavaScript 程序，它同时也是一个合法的 TypeScript 程序functiongreet(name) {    return "Hello, " + name;}// 加上类型标注之后，TypeScript 开始发挥作用functiongreet(name: string): string{    return "Hello, " + name;}

这个决策的战略意义，在当时没有几个人看得懂：创造一种更优雅的新语言不难——你做几个漂亮的语法设计、写一篇雄文解释为什么它比 JS 好一万倍，Hacker News 首页能待一整天，但让程序员们真的迁移过去，是另一回事。

Hejlsberg 对这个问题的判断冷静到了残酷的地步。他的原话是：“每当有人跑来跟我说，‘我想创造一种新的编程语言，它能做这个做那个，太棒了’——我第一条建议就是：这个世界需要新编程语言的程度，跟需要脑袋上多一个洞的程度差不多。”

“如果你决定做一门语言，你要意识到，90% 的事情是每一门语言都要做的，而门槛还在不断提高。现在的程序员不只需要一个编译器——他们还需要语言服务（能集成到所有主流 IDE 里）、调试器、性能分析器、MCP 服务器……这个清单越来越长。然后你还得准备十年的冷板凳，因为一门语言从出生到有意义的用户量，至少需要那么久。头五年你会饿死的，用户不够多，资方会一直问‘我们真的要继续投这个吗’。”

他说这段话的时候语气很平静，但内容是一笔清清楚楚的经济账：要让一门新语言成功，你需要同时打赢编译器战争、工具链战争、IDE 集成战争、社区战争和时间战争，五条战线，任何一条输了，全局就输了。

TypeScript 的策略是把五条战线的战争缩减成一条：只打类型系统这一条，其他四条——语法、运行时、工具链、社区——全部继承 JavaScript 已有的。你写的就是 JS，你的 JS 工具全都能用，你的 JS 依赖全都能跑，TypeScript 只是在上面多了一层类型检查。

“JavaScript 对我们来说就是没有类型标注的 TypeScript，”Hejlsberg 说，这意味着微软不需要同时维护 JS 工具链和 TS 工具链——它们是同一套东西，你在 VS Code 里写的 JS，享受的是跟 TS 完全相同的语言服务。

这就是 TypeScript 赢了而 CoffeeScript 和 Dart 没有赢的原因：TypeScript 要求用户付出的迁移成本是零——你可以把 .js 文件重命名为 .ts，编译器不会抱怨任何一个字符，然后你再一个变量一个变量地加类型，按你自己的节奏，不需要一次到位。CoffeeScript 的语法比 JS 漂亮得多，但漂亮不值钱，零迁移成本值钱。

有人可能要说了，这听起来不就是“向现实低头”吗？语言设计者的尊严呢？不该创造更好的东西吗？

这个问题问反了。语言设计者的尊严，应该用“有多少人因为你的设计而少吃了苦”来衡量——用“我创造了什么新东西”来衡量，是评教授职称的逻辑，是产品经理的逻辑。TypeScript 今天有几千万开发者在使用，它选的路径在理论上一点也不性感，在实践中极度有效：不要让你的用户搬家，直接把他们已经在住的房子修好。

Go 移植：10 倍的诱惑和“不重写”的纪律

2024 年夏天，TypeScript 团队面临一个决策，这个决策的残酷程度，足以让任何一个技术人员在半夜惊醒。

TypeScript 编译器从一开始就是用 TypeScript 自己写的——自举，这在语言社区里是一个骄傲的传统，编译器用自己的语言写，意味着你“吃自己的狗粮”，你的语言必须好到足够写编译器，而且这还带来了一个额外红利：编译器本身就可以跑在浏览器里，所以你可以做基于浏览器的 IDE——就像 VS Code for Web 那样，编辑器里内置一个完整的语言服务，直接在浏览器端完成类型检查。

但这个架构有一个物理上限。

JavaScript 是单线程的，在 V8 里再怎么优化，你也无法使用共享内存并发——那 90% 以上的 CPU 算力就永远躺在那里，你用不了。同时 JavaScript 的对象模型极其灵活，你可以随时往任意对象上拍新的属性，这种灵活性让 JIT 编译器很难生成真正紧凑的机器码——最终运行时还是某种哈希表查找，加几层缓存，再加一些奇技淫巧，永远到不了原生代码的速度。

Hejlsberg 的原话更直白：“我们知道，明明有那么多性能摆在那里，我们就是拿不到。”

2024 年夏天，团队开始做原型验证：把扫描器和解析器移植到原生代码里，跑了一下性能对比。

结果是 10 倍。

“你没法对 10 倍视而不见，”Hejlsberg 说，“这改变了一切。以前要几分钟的事情，现在 10 秒。你只能跟着它走。”

10 倍是怎么来的？一半来自原生代码本身（没有 JS 运行时的开销），一半来自共享内存并发（终于能用上所有 CPU 核心了），两个因素叠加，单线程解释型语言和原生并发之间的鸿沟一目了然。

但接下来团队要做出的第二个决策，比“要不要移植”更难。

社区里铺天盖地的声音是：“既然要重写，当然用 Rust 啊！”“用 Rust 重写编译器，安全、现代、性能拉满，这不就是完美的选择吗？”

Hejlsberg 的回答，可以说是整个访谈里最见功力的一段。

“我们很快就排除了 Rust。我们的编译器里到处都是循环数据结构，我们需要自动垃圾回收——Rust 不提供这些。用 Rust，这就变成了一次重写。移植和重写之间隔着一条巨大的鸿沟。”

注意这里的措辞。“重写”和“移植”之间的区别，是理解 Hejlsberg 全部四十年决策逻辑的核心密钥。

重写意味着你从零开始设计数据结构和算法，你追求的是“新的这个比旧的更好”——更优雅、更快、更安全。但代价是：旧编译器里积累了十几年的语义行为，那些细节没有写在任何文档里，全部编码在代码的执行逻辑中——边界情况的处理、奇怪的兼容性保留、某个特定 TypeScript 版本引入的不经意行为。如果你重写，你会永远在追一个长长的尾巴：“用户报告说旧编译器行为是 A，你的新编译器行为是 B，对不上。”

移植意味着你把旧代码逐函数翻译到新语言里——保持语义完全一致，哪怕旧代码里的怪癖也一并搬过去。新编译器的目标是：给定同样的输入，产生和旧编译器逐位相同的输出（只是快了 10 倍）。

“我们真的是逐函数地移植同一份代码，”Hejlsberg 说，“甚至连旧编译器里的怪毛病——你报告过的某个 bug，新编译器里也有完全一样的 bug。只是快 10 倍，但行为一摸一样。”

这听起来像是缺点，但在兼容性这件事上，这是最宝贵的特性——TypeScript 有几千万用户，有几十万个项目，有数百万行类型定义，如果新编译器行为跟旧的不完全一致，这几千万人里总有一个会踩到坑，每多踩一个坑，社区的迁移意愿就掉一截。

Rust 的问题不光是它没有 GC 和不允许循环引用——更深层的问题是，Rust 的编程范式（所有权、借用、生命周期）会迫使你重新思考每一个数据结构的设计。换句话说，Rust 手里的锤子叫“重写”，它看什么钉子都像重写。

Go 的哲学恰好相反，Go 有 GC，有简单的对象模型，语法足够接近 TypeScript（以至于移植代码时不需要在脑子里做大量的范式转换），它允许你“逐行翻译”——这正是 TypeScript 团队需要的东西。

最终选择的语言是 Go。

来算一笔细账。移植 50 万行代码，如果选择 Rust，意味着每一行都要重新设计数据结构、重写所有权逻辑、处理生命周期标注——这本质上是把“移植”项目变成了“重写+验证”项目，人力成本和出错概率都会指数级上升，选择 Go，意味着数据结构虽然要改（原生语言不允许随便往对象上拍属性），但整体翻译的工作量是线性的——你的注意力全部花在“翻译”上，“重新设计”这四个字从一开始就不在任务清单里。

更关键的是验证成本。逐函数移植意味着你可以写自动化测试来逐函数比对新旧编译器的输出——每一个函数输入相同，输出也必须相同，这个验证过程是机械的、可自动化的，而重写的验证过程是语义的、需要人工判断的。

这又是一笔经济账，Hejlsberg 选择了验证成本更低的那条路径——即使它听起来不够“酷”。

这在开源社区里引起了不小的争议。“为什么不选 Rust”成了一个反复出现的质问。Hejlsberg 的回答很有意思：“开源是一场奇怪的舞蹈——你把东西全给出去，但它是由一个需要赚钱的商业实体资助的。总有人要付账单的。我们在选择技术栈时，优先级是‘最高效地产出正确的结果’——‘酷不酷’排在很后面。”

一年后，移植项目进展神速，团队选择了一个在 Hacker News 上可能评不了高分的语言，然后实实在在地拿到了 10 倍性能。

AI 时代的编程语言：一个反直觉的推论

访谈的最后一部分聊到了 AI，Hejlsberg 抛出了一个很多人没想过的观点。

“很多人问我，为什么不为 AI 设计一门完美的编程语言，让 AI 来生成目标代码？”

“答案是——AI 最擅长的语言，就是它见过最多的语言。”

AI 是一个巨大的“复述器”（他的原词是 regurgitator），它会的是把训练数据里见过的东西重新组合，在上面做一些外推，AI 写某种语言代码的能力，跟它在训练时见过多少这种语言的代码成严格正比。

这意味着什么？意味着新编程语言在 AI 时代处于天然劣势。你设计了一门语言，语法更优美、类型系统更合理、编译更快、包管理更现代——但 AI 没见过它，AI 哪怕只见过海量的 JavaScript 和 Python 和 TypeScript，它在这些语言上的代码生成质量就远高于你的新语言，结果就是开发者会更愿意使用 AI 擅长的语言，进一步拉大差距。

这个推论一旦成立，它实际上在说：编程语言的网络效应，在 AI 时代不但没有减弱，反而被锁死了。 在过去，如果你的语言足够好，总有一些早期采用者愿意尝鲜——性能更好、表达力更强、类型安全更高，这些优势可以吸引第一批人。但 AI 时代的开发者决策逻辑变了：当 AI 能帮你在 JS 里一分钟写出一百行经过验证的代码，在没见过的语言里却磕磕绊绊、幻觉满天飞，你选谁？

赢家通吃的格局，被 AI 这个新变量进一步焊死了。

Hejlsberg 在移植项目里也验证了这一点。“我们尝试用 AI 来自动化移植过程。效果不好。那是大概一年前，AI 比现在弱。但我们追求的是一个确定性结果——我们要移植 50 万行代码，并且知道每一行都跟原来做完全一样的事情。如果你让 AI 来翻译，它可能会这里那里幻觉一下，然后你就得逐行去检查每一行代码——这比手写还累。”

他提出了一个更聪明的用法：“让 AI 生成一个帮你做移植的程序，然后你运行这个程序来得到确定性的结果。你不用检查每一行生成代码，你只要检查那个程序对不对。”

这个思路本身就是一个经典的工程智慧：把不确定性封装在一个可控的边界内，让核心产物的每一行都是可审计的。

还有一个细节很值得留意。TypeScript 团队在移植时，有一个部分他们决定不移植——语言服务（language service）里的一些功能，语言服务是 TypeScript 在 IDE 里给你提供语句补全、代码导航、重构、快速修复这些东西的模块。

“我们看着这些功能就在想——AI 现在已经能做所有这些了，有些地方做得比我们还好。我们确实不想把十年前写的、在那个没有 AI 的语境下设计的东西一模一样的搬过去。”

但类型检查器，全部移植，因为类型检查需要确定性——它必须每次都给出完全一致的结果，跟十年前完全一致的行为。“那个绝对不能交给 AI，它必须是一个完全可预测、完全确定的系统。”

这个分界线划得非常精彩：所有需要确定性的核心逻辑，人类手工移植、逐行验证；所有可以被概率覆盖的边缘功能，扔给 AI 去增强甚至替代。 这是一条在 AI 时代做工程决策的黄金准则。

同一个配方

现在可以把四段历史叠在一起看了。

Turbo Pascal 赌的是：编译速度是程序员生产力的核心瓶颈，所有把编译速度当边缘指标的同行都赌错了，他们研究怎么生成更优的机器码时，Hejlsberg 在研究怎么把编译时间压到让用户感知不到。

C# 赌的是：平台是你要拥抱的东西，拥抱得越紧越好，Java 在赌“所有平台最终会一样”，C# 在赌“用户已经选好了平台，你要在那个平台上做到最好”。

TypeScript 赌的是：不要让你的用户搬家，不要发明新语言，去修他们正在用的。CoffeeScript 和 Dart 的语法都比 JavaScript 漂亮十倍——然后它们全输了，因为让开发者换个语言写代码的成本，远远超过“修好现有语言”的成本。

Go 移植赌的是：移植比重写便宜，兼容性比优雅重要，Rust 是全世界的宠儿，但 TypeScript 团队选了 Go——他们的目标从一开始就是“让现有的几千万用户无痛获得 10 倍性能”，谁更漂亮，不在计分板上。

这四次决策，靶心是同一个东西：

编程语言的竞争，比的从来只有一件事——谁能让开发者用最小的代价，获得最大的产出。 优雅、现代、正确，这些词在开发者真实的痛觉面前，什么都不是。

有人把这个叫“实用主义”，有人叫“开发者同理心”，Hejlsberg 自己是这么说的：“你必须是务实的。最终用户不在乎某个东西是语言特性还是框架特性还是平台特性还是编辑器的功能——他们在乎的是整个体验。所有东西必须作为一个整体工作。”

“整个体验”这四个字，就是四十年四次豪赌的全部底牌。

Turbo Pascal 的“整个体验”是一个按钮下去瞬间就跑。C# 的“整个体验”是 Windows 应用程序写起来跟 VB 一样快、跑起来跟 C++ 一样猛。TypeScript 的“整个体验”是你写 JS 的时候 IDE 突然就懂你的代码了。Go 移植的“整个体验”是你什么都没做，编译速度就快了 10 倍。

每一次，Hejlsberg 都没有在“语言设计”这个维度上跟对手竞争，他每次都上升了一个维度——在“开发者体验”上竞争，而当对手还在擂台上一拳一拳打语言特性的时候，他已经把整个擂台换了。

编程世界里有一个经久不衰的讨论：为什么语言 X 比语言 Y 好一万倍，但 Y 的用户量是 X 的一千倍？这个讨论通常会走向“大众不懂技术”“企业决策保守”“历史包袱太重”这些解释。

四十年的证据在说另一件事。

更好的语言输掉，是因为“语言更好”这个优势在整个决策体系里的权重远比你想象的小——迁移成本、工具链成熟度、社区生态、AI 训练数据量、公司内部的存量代码，这些因素的加权总和，碾压了“语法更漂亮”。

Hejlsberg 是极少数看清了这一点、并且用产品反复验证了这一点的人。他没有去设计四门”更好的语言”——他设计了四个让开发者不需要重新学任何东西就能立刻获得好处的产品。

Turbo Pascal 让你不需要学新编辑器。C# 让你不需要离开 Windows。TypeScript 让你不需要离开 JavaScript。Go 移植让你甚至不需要感知到编译器换了一个。

这就是同一个配方，用了四十年，而 Hejlsberg 在这个访谈的结尾说的最后一句话，无意中给这个配方做了最好的注脚。被问到“哪种不是你创造的编程语言让你最尊敬”时，他说：

“说实话，任何一门跟程序员有关系的语言——哪怕只是到了能让我们讨论的程度——都一定有它的好东西。我尊重它们，因为它们能走到这一步有多难，我知道。你会是一个傻子，如果你创造一门编程语言而不从别的语言那里借东西。那里有太多可以学习的东西了。”

这句话的题眼是后半句——“我知道有多难”。设计过四门成功语言的人，比任何人都清楚：语法优美从来当不了护城河，真正要命的问题永远是同一个——你能不能让真实的人类程序员，在一个又一个真实的截止日期之前，用你的东西把活干了。

Turbo Pascal 让他们少等了。C# 让他们少装了。TypeScript 让他们少学了。Go 移植让他们什么都没做，就快了 10 倍。

同一个人，同一套逻辑，四十年，这笔账算得过来的人不多。Hejlsberg 算得过来。