Go 考古：图灵奖得主 Ken Thompson 亲述，Go 语言是如何在 C++ 的“废墟”上诞生的
本文永久链接 – https://tonybai.com/2026/01/05/how-ken-thompson-developed-go-language-at-google.
大家好，我是Tony Bai。
为什么 Go 语言极其痛恨复杂的特性？为什么 Go 如此执着于编译速度？我们常说 Go 是一门“工程实用主义”的语言，它的设计哲学是“少即是多”。但你是否想过，这种近乎偏执的简洁，究竟是为了对抗什么？
这一切的答案，都藏在 2007 年 Google 内部的一场 C++ 标准委员会汇报演讲中。当图灵奖得主 Ken Thompson 发现自己竟然“看不懂”新的 C++ 特性时，一颗变革的种子就此埋下。
最近，我重温了这段 Ken Thompson（Unix 之父、Go 语言联合创始人）的珍贵访谈。在访谈中，老爷子毫无保留地讲述了 Go 语言诞生的前因后果。 故事的起点，并非某次高瞻远瞩的战略规划，而是一次“听不懂”的 C++ 技术分享，以及 Google 内部那令人绝望的 45 分钟编译时间。
本文基于 Ken Thompson 的访谈实录，带你回到那个决定性的瞬间，还原 Go 语言诞生背后的真实故事。
压死骆驼的最后一根稻草：C++ 的“新特性”
故事发生在 2007 年左右。当时，Google 内部有一位 C++ 标准委员会（ANSI C++）的代表。
有一天，这位代表刚开完标准会议回来，在 Google 内部做了一场技术分享，向大家介绍 C++ 即将引入的“新特性”（注：推测是指当时的 C++0x，即后来的 C++11 草案）。
Ken Thompson 就在台下。作为发明了 B 语言（C 语言的前身）并重写了 Unix 内核的宗师级人物，他在听完这场一小时的密集分享后，感受到的不是兴奋，而是困惑。
“这所谓的‘新东西’，在我看来比语言本身还要大。”
“那些关于指针的形式，除了指针之外还意味着其他东西……我告诉你，我没听懂。”
想象一下，连 Ken Thompson 都直言自己“没听懂” C++ 的新特性，这说明了什么？
在他看来，这些所谓的“改进”，只是在不断地堆砌复杂度。这场演讲成为了催化剂。Ken 回到办公室，找到了同样对现状不满的 Robert Griesemer 和 Rob Pike。
Ken 的不满在于语言的过度复杂，而 Rob Pike 的痛点则在于 Google 庞大的工程规模。
Google 的工程噩梦：10 行代码与 500 万行编译
当时的 Google 面临着一个前所未有的工程挑战：Monorepo（单一代码仓库）的膨胀。
Ken 在访谈中描述了一个令人窒息的场景：
“在 Google，你可以从任何源文件中引用库。你可能只写了一个 10 行的程序，但最终却需要处理 500 万行的编译量。”
这不是夸张。由于缺乏严格的依赖管理和可见性控制，一个微小的依赖引入，可能会像滚雪球一样，将底层的庞大库（如 Protocol Buffers、基础库等）全部卷入编译过程。
更糟糕的是，头文件（Header files）的包含机制导致了严重的重复劳动。
“像最简单的库，可能会被加载和检查成百上千次。”
虽然 Google 拥有当时世界上最强大的分布式编译集群（成百上千个 CPU 并行工作），虽然工程师们发明了各种缓存机制和 ifdef 技巧来避免重复包含，但物理定律是不可违背的。
编译一个简单的程序，需要等待 15 分钟，甚至 45 分钟。
Rob Pike 对此深恶痛绝。这种低效的开发循环，正在扼杀 Google 工程师的创造力。
三个火枪手与“一票否决权”
于是，在 Google 的一间办公室里，Ken Thompson、Rob Pike 和 Robert Griesemer 聚在了一起。
Ken 说出了那句改变历史的话：
“What are we going to do about it? Let’s write a language.”（我们该怎么办？让我们写个语言吧。）
这是一个完美的互补组合：
- Rob Pike：深刻理解 Google 的工程痛点（依赖地狱、构建速度、大规模协作）。
- Ken Thompson：拥有深厚的语言和编译器构建历史。
- Robert Griesemer：被称为“瑞士军刀般的语言专家”，熟悉理论上存在的所有语言特性，是团队的理论百科全书。
在设计 Go 语言时，他们制定了一个残酷但有效的规则：全员同意原则。
“我们必须都同意某个特性，它才能被加入。仅仅因为‘我想要这个特性’是不够的。”
这个规则过滤掉了绝大多数“花哨但非必要”的特性。Go 语言之所以能保持如此干净、紧凑，正是因为这三位创始人在最初就把住了关口。
遗产与未来
Ken Thompson 在 Go 语言开源并走上正轨后，逐渐淡出了核心开发。但他对 Go 的后续发展给予了极高的评价，特别是对标准库。
“在我离开后，后来的人写了一套极其出色（magnificent）的标准库。”
那之后，这位图灵奖得主在 Google 的工作中，几乎只使用 Go 语言，并且几乎只使用标准库。
他对 Go 的评价朴实无华：
“它很简单。任何人都可以在一小时内学会它。当你写代码时，它运行得足够快，给你即时的反馈。”
小结
重读这段访谈，我们就能理解：
- 为什么 Go 甚至不愿意引入三元运算符？
- 为什么 Go 的依赖管理（Go Modules）对版本控制如此严格？
- 为什么 Go 编译器宁愿牺牲一些优化也要保证极快的编译速度？
因为 Go 从诞生的那一刻起，就是为了反抗 C++ 的过度复杂，和解决 Google 级别的工程规模问题。
它不是为了在编程语言理论上创新，而是为了让像 Ken Thompson 和 Rob Pike 这样的工程师，不再需要在编译期等待 45 分钟，不再需要去猜测一段代码到底在通过指针玩什么花样。
Go 的诞生，是工程实用主义对无节制复杂性的一次伟大胜利。
资料链接：https://www.youtube.com/watch?v=NTrAISNdf70
你的“编译等待”时刻
45分钟的编译时间催生了Go语言。在你的开发生涯中，是否也经历过类似的“编译噩梦”？或者，你是否也曾被某些语言的“过度复杂”劝退过？
欢迎在评论区分享你的故事！ 让我们一起致敬那些为了“简单”而努力的先驱。
如果这篇文章让你对Go语言的设计哲学有了更深的理解，别忘了点个【赞】和【在看】，并转发给身边还在忍受漫长编译的朋友！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
- 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
- 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
- 想打造生产级的Go服务，却在工程化实践中屡屡受挫？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
评论