Go - Tony Bai

标签 Go 下的文章

Go 考古：图灵奖得主 Ken Thompson 亲述，Go 语言是如何在 C++ 的“废墟”上诞生的

一月 5, 2026
0 条评论

本文永久链接 – 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技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

让编译器成为你的副驾驶：告别“防御性编程”，拥抱“类型驱动开发”

一月 4, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/01/04/stop-lying-to-the-compiler

大家好，我是Tony Bai。

“半夜被值班的运维同事叫醒，发现生产环境崩了，原因是一个深藏在业务逻辑里的 nil 指针异常。”

这个场景，对于每个后端开发者来说都是挥之不去的噩梦。事后复盘时，我们往往会懊恼：“为什么这里没加 if != nil 判断？”然后，我们在代码里撒上一把防御性检查的“盐”，祈祷下次好运。

但这真的是解决之道吗？

最近，Daniel Beskin 的一篇深度好文《The Compiler Is Your Best Friend, Stop Lying to It》（编译器是你最好的朋友，别再对它撒谎了），为我们提供了一个全新的视角：这些运行时崩溃，本质上是因为我们在编译时对编译器撒了谎。

我们告诉编译器“这是一个字符串”，但实际上它可能是 nil；我们告诉编译器“这个函数返回一个整数”，但实际上它可能抛出一个 panic。当我们停止撒谎，开始用类型系统表达真实意图时，编译器将从一个“报错机器”，变成我们最强大的“安全副驾驶”。

我们对编译器撒过的“谎”

在 Go 语言的日常开发中，我们常常为了“方便”而向编译器撒谎，埋下了日后爆炸的地雷。

谎言一：隐形的 nil

当我们定义 func Process(u *User) 时，我们告诉编译器：“给我一个 User，我处理它。” 但在 Go 中，指针可以是 nil。
* 谎言：我承诺会处理一个 User。
* 真相：我可能会收到一个 nil，然后炸掉。
* 后果：为了弥补这个谎言，我们需要在函数内部写无数的 if u == nil 防御性代码。一旦遗漏，就是生产事故。

谎言二：盲目的类型断言与 any

当我们使用 interface{} (或 any) 时，我们实际上是在对编译器说：“别管这个，我知道我在做什么。”
* 谎言：这个 any 类型的变量，其实是一个 int。
* 真相：它可能是一个 string，或者 nil。
* 后果：运行时的 panic: interface conversion: interface {} is string, not int。

谎言三：隐藏的副作用与 Panic

当我们看到一个函数签名 func Parse(s string) int 时，编译器认为它是一个将字符串映射为整数的函数。
* 谎言：这是一个纯粹的转换函数。
* 真相：如果字符串格式不对，我会直接 panic，中断整个 goroutine。
* 后果：调用者无法通过函数签名预知风险，导致程序在边缘情况下意外崩溃。

停止撒谎，开启“对话”

如何重建与编译器的信任关系？答案是：将运行时的检查，提前到编译时的类型定义中。

策略一：让非法状态无法表示

这是消除 nil 和无效数据的终极心法。

场景：一个配置项 Port，如果是 0 表示随机端口，如果是正数表示指定端口。
糟糕的设计：Port int。你必须在代码各处检查 Port < 0 的情况，并且含义模糊。
诚实的设计：
```
type Port int

// 使用构造函数来保证 Port 的合法性
func NewPort(p int) (Port, error) {
    if p < 0 || p > 65535 {
        return 0, fmt.Errorf("invalid port")
    }
    return Port(p), nil
}
```
一旦你通过 NewPort 拥有了一个 Port 类型的值，编译器就为你担保：它一定是一个合法的端口号。你后续不再需要防御性检查(未通过NewPort获得的除外)。

策略二：用类型区分概念

场景：用户 ID 和订单 ID 都是 int64。
糟糕的设计：func GetOrder(userID, orderID int64)。调用者很容易把两个 ID 传反，而编译器毫无察觉。
诚实的设计：
```
type UserID int64
type OrderID int64

func GetOrder(uid UserID, oid OrderID) { ... }
```
现在，如果你试图把 UserID 传给 OrderID，编译器会直接报错。这不是繁琐，这是编译器在帮你 Review 代码。

策略三：显式的可空性

虽然 Go 没有 Rust 的 Option，但我们可以利用指针的语义来诚实地表达“可能不存在”。

场景：更新用户信息，只更新非空字段。
诚实的设计：
go type UpdateUserRequest struct { Name *string // nil 表示不更新，非 nil 表示更新为新值 Age *int }
这里，指针不再是“可能导致崩溃的引用”，而是“可选值”的显式类型标记。这让代码的意图对编译器和人类都一目了然。