继裁掉 Python 团队后，谷歌 Go 团队也迎来动荡：团队灵魂人物、领导 Go 十二年的技术负责人突然宣布退位

就在一年一度的大规模开发者会议召开之前几周，谷歌最近迅速出手裁撤了 Flutter、Dart 和 Python 团队，旋即引起科技界的广泛关注。据报道，被裁撤的岗位将被转移至印度和墨西哥等地，旨在简化运营并减少公司内部的层级。很多人认为虽然谷歌可以无情放弃这些项目，但绝对不会“伤害”自创编程语言 Golang。

这是因为 Golang 代码的作用就是在底层默默运行，保证一切能够正常运转——从 Google Cloud Platform 到 YouTube，再到谷歌 Play Store 应用商店，该语言已经成为谷歌众多核心产品与基础设施的核心支柱。也就是说，放弃 Golang 团队意味着破坏谷歌软件生态系统的运行基础。

但让人意外的是，现在谷歌 Go 团队还是迎来了动荡：领导 Go 团队和整个 Go 项目的 Russ Cox 突然宣布卸任技术负责人。Russ Cox 管理谷歌 Go 语言超过 12 年、工作超 18 年，是 Go 语言初始团队成员。

Go 技术领导人宣布卸任，转战 AI 相关项目

昨天，Russ Cox 给“golang-dev”群组发送了邮件通知：

从 9 月 1 日开始，Austin Clements 将接任 Go 项目技术负责人：包括统领谷歌 Go 团队以及整个 Go 项目。Austin 此前担任所谓“Go 核心”技术负责人，具体涵盖编译器工具链、运行时及发布工作。原本由 Austin 承担的这部分工作，将由 Cherry Mui 接掌管理。

 

我本人并不会脱离 Go 项目，但现在也到了做出调整的合适时机。首先需要强调的是，与任何其他领导职务一样，技术负责人是一种服务角色、而非荣誉头衔。我已经领导 Go 项目超过 12 年了，为众多社区成员提供服务，也努力为大家创造更适合的开发条件、帮助各位发挥出最佳水平。像 Go 这样的大型项目当然应该拥有稳定的领导架构，但适当的领导层变动对于项目也是有益无害。新任领导班子将带来新的推力和新的视角。

 

对于 Go，我认为长达 12 年的管理已经足够稳定，是时候让新人接过担子、翻开新篇章了。更具体地讲，无论对于个人还是项目来说，我都不太认同“BDFL”（仁慈的终身独裁者）是种健康的管理模式。其中最大的问题就是无法为新任领导者创造空间，自然也成了单点故障的源头。这将扼杀项目的后续发展空间。我认为 Python 就伴随着 Guido 在 2018 年卸任，将权柄移交他人而受益匪浅。所以多年来我也一直在想，Go 项目最终也必须迎接一波领导层变革。

接棒的 Austin Clements 自 2014 年以来一直在谷歌从事 Go 方面的工作，Cherry 则是在 2016 年加入了 Go 项目组。另外，Go 的另两支子团队则继续保持不变：Roland Shoemaker 将继续主管 Go 安全，Rob Findley 和 Hana Kim 则继续肩负 Go 工具和 IDE 支持方面的工作。

之后，Russ Cox 将把重点转移到 AI 项目 Gaby 和Oscar身上，专注于 Go 问题跟踪器的改进。其中，Oscar 是一个开源的贡献者 Agent 架构。不久前 Russ Cox 透露了它的第一个原型 gabyhelp：https://github.com/gabyhelp。此外，Gaby 是一个旨在帮助自动化 Go 问题跟踪器的工具。

Russ Cox 的网名是 rsc，他于 2008 年在麻省理工学院（MIT）获得博士学位，本科和研究生阶段均在哈佛大学就读。在哈佛大学就读期间，Russ 在贝尔实验室实习。由于贝尔实验室靠近他成长的家，他从高中起就经常在实验室的计算机科学部门学习和工作，与 Rob Pike 一起开发了贝尔实验室的分布式操作系统 Plan 9（这是 20 世纪 80 年代末由 Ken Thompson 和 Rob Pike 等人发起和领导的项目）。

之后，Russ 在 MIT 攻读博士学位期间，还曾在谷歌实习。在博士即将毕业时，Rob Pike 和 Ken Thompson 向他介绍了他们正在设计的新语言 Go，并邀请他加入他们的团队，表示：“嘿，我们正在尝试将以前在 Plan 9 开发软件时非常喜欢的所有东西用在我们想在谷歌里写的软件里，你想过来帮忙一起搞吗？”就这样，Russ 被这两位传奇程序员拉入了 Go 语言的开发团队。

担任 Go 团队的技术主管多年，Russ Cox 不久前接受采访，表示自己应付工作已经变得像鱼在水中一样自然。

他的主要任务之一是尽量减少工作中的摩擦，在提案过程中努力用更多方式让人们参与进来，并让他们以有意义的方式做出贡献，确保社区成员的声音能够被听到。在日常工作中，Russ Cox 也需要根据具体情况进行分析。有时候，解决一个问题可能需要花十天半个月编写新代码，这个过程虽然有趣，但通常只会产生某种原型，还不足以让团队的其他成员顺利接纳，更不用提彻底取代原本的方案。所以，他的任务是证明这些原型的“可能性和结构可行性”，然后说服团队开发出真正能用的生产级版本。

Russ Cox 的工作还包括与各种人会面，参与设计审查，讨论工作进展并了解他们的工作，尝试以有用的方式引导事情向好的方向发展。即使是最简单的问题，只要发现有人被其困扰，他会说“其实我们有个思路，但已经好几年没讨论过了，你看看有没有帮助。”

这种角色对团队有很大作用，而且每天的工作内容都不一样。

Go 语言团队的工程总监 Sameer Ajmani 是这么评论 Russ Cox 的：“Go 团队中有很多极具才华的成员。当然，聪明人哪里都有，但谷歌这边就是聪明头脑的大本营，而 Go 团队总体上更胜一筹……Russ 则站在所有这些人的顶端！类似于那种才华横溢、全面发展的‘别人家孩子’……我其实经常会关注他有哪方面比较弱势，但到现在为止都没找到。”

针对 Russ Cox 的卸任，微软、华为等企业的 Go 团队都表达了对他的感谢。

也有一些网友表达了对继任者的期许：

重大消息！我希望新领导层记住，保持 Go 语言简洁小巧是其最大优势。添加泛型过于复杂，虽然我认为在某些重要的小范围场景中它有价值，但实际上人们在不应该使用它的时候也在用。我还希望看到谷歌对该项目的控制减少。

Go 项目管理

作为一个发源自谷歌的项目，Go 整个技术栈目前完全在谷歌 Go 团队掌控之下。Russ Cox 不久前（今年 6 月份）刚分享过自己作为 Go 项目负责人的管理心得。

Russ Cox 和他的团队主要采取分布式的规划，因为 Go 项目有三个子团队。每个都有自己的分工和计划，其中包括工具团队和安全团队。Russ Cox 不会具体决定每个人下周要做什么工作。他认为管得那么细并不是好事。

其中最重要的是设定目标。在 Go 语言诞生之初，设定的目标就是希望它能够适应两种不同规模的需求：一方面是适应大量机器、大量数据以及巨大设施规模的生产需求；另一方面是适用于人员规模可观的大型项目，特别是适应具有不同技术背景和偏好的参与者。换句话说，哪怕只是一支五人的小团队，只要选择使用开源软件，那就意味着是在与成千上万人协同工作。所以，Russ Cox 希望 Go 能够更好地适应这两方面的规模需求。

实际上，在 Go 的演进过程中，做出改变其实相当困难。任何改变，特别是语言层面的改变，必然会引发从编译器开始的一系列震动，包括修复与编译器相关的所有工具、gopls、说明文档等等。对于库的更改，他们一直希望能够将发布的 API 支持周期维持在十年以上。因此，Russ Cox 和他的团队的目标是做出让未来 10 年内都认可并满意的决定。这就是他们当前所追求的标准。所以，具体该做什么，取决于“其是否符合实际生产规模和人员规模”，以及“短期内是否令人满意。”毕竟纵观整个项目生命周期，不满意永远是暂时的，满意才是恒久的目标。因此，他们必须保证只为确认的关键工作开绿灯。

而在规划方面，有时候也会出现某些成果在公司内部和外部用例不同的情况，这种兼容性问题也需要优先考虑。Russ Cox 特别提到了关于 Kubernetes 的兼容性问题。Kubernetes 是一个公共开源项目，目前得到所有主流云服务商的采纳。另外还有谷歌 Kubernetes Engine 团队，这也是谷歌的主要收入来源。“我们会将其视为合作伙伴团队，帮助他们更好地服务于客户，毕竟他们伺候的可是谷歌的金主。”为此，Go 团队会围绕 Kubernetes 团队的需求调整 Go 的发展方向，同时也需要向 Kubernetes 乃至他们的服务对象解释自己的一些考量和选择，努力以一种不单纯服务于谷歌或者 Kubernetes 的方式设计发展路线。

Russ Cox 举了一个具体的例子。

最近 Kubernetes 团队找到 Russ Cox，表示 Go 团队“一直在以零零碎碎的方式破坏我们的工作，但实际上又没有直接违反兼容性政策……”例如，在修复一个 bug 的时候，规范版本要求 IP 地址应该以 0 开头。那么 18.26.014 合不合规？这里的 14 是十进制、十二进制还是八进制？事实证明，所有 BSD IP 地址解析器都会将其视为八进制。然而，当他们用 Go 编写 IP 地址解析器时并不清楚这一点，所以仍然沿用十进制。更直白地讲，不同工具在读取过程中，对含义的理解是存在分歧的。因此，他们就做出了调整，严禁 IP 地址以 0 开头。

但很多东西一旦发布就很难更改，但 Russ Cox 和他的团队可以说“从现在起直接拒绝解析。”所以如今在接受 IP 地址的时候，老用户也不会感觉出有什么变化。只是 Kubernetes 团队会担心，他们的某些配置会以 0 开头，还带有复杂的小数位。这是 Go 的弊端之一，这种情况会破坏用户体验。因此，他们决定对此做出更改，防止此类问题继续出现。

最终的方案是，这些变更不会被直接触发，除非用户在 go.mod 中更新了 Go 版本。这意味着 Kubernetes 既可以迁移至较新的工具链，又能继续保留原有 Go 版本，也就是先把旧版本的兼容性问题搁置起来。这就是他们判断工作优先级的一个案例，因为有团队明确提醒，“因为存在这些小 bug，所以我们没办法马上更新到最新 Go 版本，自然也就无法提供安全更新。”

总之，Go 团队做了很多工作来解决这些小麻烦，而且这些小麻烦之间还有千丝万缕的联系，非常不容易。

Go 之于谷歌

同样是来自谷歌的项目，相对于 Dart 或 Flutter，开发者显然对 Go 更有信心，一方面是对开发 Go 的人有信心，另一方面是 Go 在谷歌内部和外部都有巨大的吸引力，而 Dart/Flutter 从未获得过很大的吸引力。

人们并不是“对谷歌有信心”，而是对从事 Go 语言开发的团队有信心。

回顾 Go 的发展，起初是因为谷歌需要一种能够处理其庞大工程规模与复杂需求的软件开发语言，具备快速编译、轻松并发且高效内存管理等特性。而现有语言根本无法满足其这些需要。

在此之前，C++项目必须依靠集群才能加快编译时间。这延长了编译周期，同时也不适合管理大规模计算集群或者构建 Web 规模的大型应用程序。

Go 语言的共同缔造者 Rob Pike 写道，“多核处理器、网络系统、大规模计算集群乃至 Web 编程模型带来的诸多问题只能规避，却无法得到正面解决。”

除此之外，Go 最大的影响也可以说来自云原生领域。2014 年，谷歌使用 Go 开发并发布了 Kubernetes。作为一套开源容器编排平台，Kubernetes 迅速成为客观意义上的行业标准。

Pike 解释称，Go 的使用范围已经全面超越了 Kubernetes。“该语言占领了云世界的高地——Grant、Docker、Kubernetes、Envoy、Pantheon 等等，几乎云原生计算基础中的一切都与 Go 有关。也可以说，Go 就是描述云基础设施的语言。”

多年以来，Go 在谷歌的地位可谓只升不降。近期案例研究再次强调，谷歌搜索索引从单体式 C++管线正向着 Go 微服务架构转变。另外一项研究也表明，Chrome 优化指南服务器也正是依靠 Go，才能每天向数百万移动用户提供更快的页面加载速度。

此外，部署 Web 应用程序和静态内容的 Firebase 也已将其后端从 Node.js 迁移至 Go，旨在提高并发性与运行效率。Go 还取代了谷歌原本用于搜索质量分析的编程语言 Sawzall。

Go 的重要意义也远远超脱于谷歌之外。自 2009 年开源以来，Go 凭借其出色的易用性、高性能以及不断壮大的库和工具生态系统，而被世界各地的开发人员所采用。

不光是 Go 本体广为人知，其支持的配置管理工具 Terraform、分布式 SQL 数据库 CockroachDB 以及时间序列数据库 InfuxDB 同样名动一时。

Uber、Twitch、Dropbox 和 Salesforce 等知名大厂都已将 Go 用于其基础设施中的关键部分。特别是 Salesforce，旗下 Einstein Analytics 平台已经从 Python 正式转向 Go。根据 Salesforce 首席架构师 Guillaume Le Stum 的介绍，“在 Python 语言中，开发者可以编写出极其优雅的列表推导与几乎完全数学化的优美代码。但这种优雅，往往也是在以牺牲可读性为代价。”

参考链接：

https://groups.google.com/g/golang-dev/c/0OqBkS2RzWw

https://mastodon.social/@golang_discussions/112693038924249374

https://news.ycombinator.com/item?id=41132669&p=1

https://changelog.com/gotime/318

https://analyticsindiamag.com/ai-insights-analysis/why-google-cant-let-go-of-golang/