[译] How things get done on the Go Team

6天前，掌舵Go语言团队12年Rsc在golang-dev/群组发文宣布，将在9月1号后辞去当前职位，转去做 Gaby 和 Oscar. 这对于Go语言发展无疑是里程碑式的事件。

本篇内容是根据6月份他和另外两位同事参与Go Time音频录制内容的整理与翻译，英文原文在gotime/go-time-318.md，过程中为符合中文惯用表达有适当删改, 版权归原作者所有.

Angelica Hill: 欢迎收听Go Time。今天我们有一个特别的节目。我们邀请到了来自Google Go团队的Cameron Balahan、Sameer Ajmani和Russ Cox。他们将和我们讨论Go团队是如何工作的。他们如何决定要改进什么？如何决定改进这些事情的顺序？除了决定要做什么，他们还会讨论什么时候做——是现在做，还是下周或明年做？然后我们会听听他们各自对Go未来的看法。当他们展望未来时，他们看到了什么？我非常兴奋能邀请到你们来参加节目。在我们开始之前，让我先简单介绍一下——正如我提到的: Cameron Balahan，他是Google的Go编程语言产品负责人; Sameer Ajmani，他是Google的工程总监，负责领导Go编程语言团队。最后，Russ Cox，他是Google的Go主要编程语言技术负责人。大家好！

Russ Cox: 你好。

Angelica Hill: 大家好吗？

Sameer Ajmani: 你好，安吉丽卡。

Cameron Balahan: 很高兴来到这里。

Angelica Hill: 我们状态如何？

Cameron Balahan: 状态很好。

Sameer Ajmani: 很兴奋能来到这里。

Russ Cox: 很高兴来到这里。

Angelica Hill: 太棒了。那么我们从一个非常基本的问题开始...对于那些可能不熟悉你们在Go领域的工作，或者可能没有看过你们做的许多精彩演讲的人，我想听听你们是如何走到今天这一步的。你们是如何进入Go领域的？也许我们可以从你开始，Russ。

Russ Cox: 我进入Go是因为我之前在贝尔实验室与Rob Pike和Ken Thompson一起工作过。我在大学时期在那里做过暑期实习生。所以当Rob去了Google后，我一直和他保持联系，当他开始从事Go的工作时，我正在读研究生，他说"你应该来加入我们。"然后我就加入了。从那以后我一直在从事Go的工作。所以已经有很多年了。很难计算具体时间... 16年了。

Angelica Hill: 太棒了。那么Sameer，你的Go之旅是怎样的？

Sameer Ajmani: 我2004年加入Google，主要用C++构建系统。大约在2010年左右，Rob Pike来做了一个关于他和他的团队正在开发的一种叫做Go的新编程语言的教程...我对此非常感兴趣，我认为它真的很酷，特别是我可以看到它如何简化我在C++中进行的大量分布式系统编程。

所以我开始在业余时间贡献。Google有名的20%时间 --- 我用它来为Google内部的Go库做贡献。最终，Russ安排了一次会面。我们在MIT读研究生时就认识了...他说"嘿，你想全职从事Go工作吗？我们正在寻找人来构建我们在Google内部的库套件。"所以我在2012年加入了团队。

<font size=1 color="orange">
(译者注: Google 的"20%时间"是指鼓励员工利用周工作时间的20%进行自主研究和创新项目的开发)
</font>

Angelica Hill: 那么Cameron，你是如何听说Go的？

Cameron Balahan: 我是这里相对是新人...我在Google才工作了四年。在此之前，我的职业道路可能有点不集中，这在事后看来可能不是最优的...但我实际上当过一段时间的律师，做了一些完全不相关的事情。然后我在高频交易领域工作了将近十年，在那里我大量使用C++和一些Java，编写低延迟交易基础设施...我一直很欣赏那些贴近底层的东西，了解事物在深层次上是如何运作的...所以当我加入Google并且Go成为一个选项时，我想"哇，多么好的机会啊。"所以我想我加入Go是因为我很幸运。

Sameer Ajmani: 我也是。

Russ Cox: 我想我们都觉得能参与这个项目非常幸运。

Angelica Hill: 太棒了。所以我的假设是 --- 对于那些可能不知道这一点的人来说 --- Russ，当你加入Go时，它还处于非常早期的阶段，只有几个人在开发...然后它逐渐发展，然后Sameer，你加入了，然后当Cameron你加入时，Google已经有了一个成熟的团队。你能告诉我一下Go团队现在是如何组成的吗？从某人有了一个想法，开始工作，然后Sameer，你利用20%的时间参与其中...到现在已经成为一个非常成熟、功能齐全的团队，这个过程是怎样的？

Sameer Ajmani: 当然，我可以谈谈这个。一开始只有三个人: Rob Pike、Robert Griesemer和Ken Thompson。很快Russ Cox和Ian Lance Taylor也加入了。我认为这五个人是最初的Go团队。到我2012年加入时，我想大约有十几个人，那时他们正准备发布Go 1.0。所以你可以说我是在团队发布1.0版本时加入的。

我开始管理一个专注于Google内部Go的子团队，然后到2016年，我转向管理整个Go团队。那时我们已经有超过20人了。之后Go团队继续增长，特别是当我们扩展到云领域，并与Google的云业务保持一致时。这是我们增长的重要部分。那也是我们开始建立跨职能团队的时候，除了核心团队之外，我们开始有了产品经理、UX 研究人员、开发者关系合作团队、项目经理等。所以我们真的开始学习如何在更广泛的Google企业中作为一个团队运作，超越了更多的小规模项目。多年来，团队已经发生了很大的变化。我们内部的具体组织方式取决于我们的关注点，我们稍后会在播客中详细讨论这一点。

Angelica Hill: 那么在有这个内部的Go团队的同时，还有这个非常丰富的开源社区...Go是一个非常活跃的社区，我们喜欢见面，喜欢互相交流...但我想多了解一下这两个社区是如何互动的，当你有一个正式的团队，但你又有开发者在那里贡献，你有这个非常丰富的开源社区。

Russ Cox: 是的，有很多不同层次的互动。最非正式的可能是像Slack和邮件列表，Go团队的人只是参与其中...也许他们有更多的知识可以分享，但在那里大家基本上是平等的参与者。然后你有问题追踪器，我们的很多工作都在那里完成，任何想要在问题追踪器上闲逛的贡献者都随时欢迎。有些人的日常工作就是在问题追踪器上闲逛，所以你经常会看到他们，然后还有一些人在那里是因为他们关心某个特定的问题，或者有些人在那里只是因为他们喜欢这样做，但他们并没有因此得到报酬...所以你会看到不同程度的活动，这很好。真正让事情运转起来需要所有这些不同层次的参与。

我们有最正式的互动方式是提案流程，我们已经开始了很多年了。我写了一系列博客文章，讨论如何管理一个开源项目，如何做决策，我们创建了提案流程，有一种正式的方式让每个人都参与到决策中来，从像我们要在字符串包中添加什么新函数这样小的事情，到"我们应该在Go工具链中添加遥测吗"这样大的事情，它真的适用于所有这些。但提案流程的目标是有一个明确的地方，任何想要贡献和参与的人都可以参与其中。

Angelica Hill: 那么通常，在Go团队的工作方式方面，我知道你们中的一些人提到团队的组成会根据团队的重点，根据你们认为语言创新所在的地方而变化...Russ，你提到了提案流程...我很感兴趣地想了解 --- Cameron，从你作为产品经理的角度来看 --- 你是如何看待所有这些不同的想法流？你有你的提案，你有从你们各自不同角色对语言创新的个人看法...然后你有实际的Go工程师团队，我相信他们有大量的想法。事情是如何真正完成的？你们如何决定"好的，这就是这个团队要做的事情？"也许因为你提到了，Sameer，如果团队正在变化，如果你们正在改变团队的组成，你们是如何做出这些决定的？

Sameer Ajmani: 这是一个很好的问题。目前的Go团队主要分为三个大的子团队。 我们有所谓的核心子团队，负责编译器、运行时、链接器，并运行核心发布流程。我们有工具子团队，负责我们的构建系统、Go命令，以及我们的IDE插件和gopls语言服务器后端，这与核心发布流程是分开的。这是我们最近几年投资较多的领域。我想在过去五六年里，我们真的专注于构建我们的IDE体验。

更近期的是，我们专门建立了一个专注于安全的子团队。大约几年前，新闻中出现了几起重大的开源供应链安全攻击。Codecov、SolarWinds...这大约是在我们开发Go模块系统的同时...我们认识到Go有机会真正解决我们的模块系统和构建系统中的一些供应链安全问题，某种程度上也在语言本身中解决。所以我们接受了这个机会，说"我们要让我们团队的一部分真正专注于Go安全，如何处理安全报告，如何进行漏洞扫描，如何思考Go程序的组成..."这已经取得了很好的效果。这也是我们需要与Google对Go的兴趣保持一致的案例，以及使用Go的Google客户的关注点，以及我们内部使用Go的系统。

<font size=1 color="orange">

(译者注:

Codecov 和 SolarWinds 是两家软件公司,都因为安全相关的事件而引起广泛关注。

Codecov:

• Codecov 是一家代码覆盖率分析服务提供商,帮助开发者衡量和改善他们的代码质量。
• 2021 年,Codecov 遭遇了一起严重的安全漏洞事件,造成数千家公司的机密数据泄露。该漏洞被黑客利用,从 Codecov 的系统渗透到客户的系统中。
• 这起事件引发了关于供应链安全的广泛讨论,凸显了第三方服务提供商的安全性对客户系统的重要性。

SolarWinds:

• SolarWinds 是一家 IT 基础设施管理软件公司,其产品被广泛用于企业网络监控和管理。
• 2020 年,SolarWinds 的软件遭遇了一起严重的供应链攻击事件。黑客在 SolarWinds 的软件更新中植入了恶意代码,导致数千家公司和政府机构的系统被入侵。
• 这起"SolarWinds事件"被认为是近年来最严重的网络安全事件之一,突显了软件供应链安全的重要性。许多公司和政府机构由此受到重创。

Codecov 和 SolarWinds 事件揭示了第三方服务提供商和软件供应链安全面临的严峻挑战,引发了业界和政府对此的广泛关注和应对措施。)

</font>

Cameron Balahan: 补充一下，我认为另一种思考方式是Go的两个主要利益相关者，一个是Go用户和Go社区，他们从Go中寻求什么价值...另一个是Google。所以Google显然对确保其内部系统运行良好，其开发人员满意，其系统可靠、安全等感兴趣...然后事实证明，外部Go开发人员也想要这些。Google还希望这些外部Go开发人员能够成功和快乐，不仅仅是出于善意，而是因为这样这些开发人员就能更成功，更快地创造价值，或者构建更可靠的软件，更安全的软件...所有这些都有助于Google的开发者平台，然后也有助于其更大的业务；让互联网成为一个运作良好的地方，让公司能够构建他们的产品并推出它们，让用户使用它们，这符合Google的利益。

对于用户来说,我认为我们一直关注的一个价值点就是生产力。虽然有很多高生产力的编程语言,但 Go 语言的重点是保持简单。它提供了一个整体的平台,让所有部分都连接在一起,让用户可以获得端到端的解决方案,无需借助第三方工具和其他复杂的额外工具。

它同时也确保你创建的高效软件是一些最可靠、安全、高性能的软件。因为这真的很重要，确保你不会花时间更新东西或修复东西。你可以集中精力构建新的东西。

所以这实际上提供了一个很好的视角来思考一切。比如，"好吧，如果我们构建新东西，这如何进一步推进我们的使命，确保我们的开发人员在各处都更有效率，他们正在构建将使他们更成功的生产级别的东西？"这让Google满意，让我们的用户满意，让社区满意，然后Go团队也对此感到非常满意。

分隔标记：[13:53]

Angelica Hill: 那么Russ,作为Go团队的技术负责人是什么感觉?你的日常工作是什么样的?你是不是整天都在和团队交谈,思考自己的有趣想法?我很好奇了解你与这些不同团队的互动是什么样的,作为这个拥有如此多用户的庞大语言的技术负责人意味着什么?我的意思是,就像我们过去看到的那样,你做出一个改变,有些人喜欢,有些人却大为不满。所以我很想了解你是如何看待自己的角色的,以及这到底是什么感觉。

Russ Cox: [笑] 我不知道这是什么感觉。我做这个工作已经很长时间了,就像鱼在水里一样自然。 但我的部分工作是尽量减少争议。我认为这确实是我们从提案流程中学到的,我们需要更多方式让人们参与进来,让他们有意义地贡献并确保他们的声音被听到。这真的是一个重要的部分。我认为自从我们真正实施提案流程以来,我们就没有再遇到那种问题。

举个例子,遥测...我们只听到关于遥测的正面反馈。这真是令人惊讶,主要是因为我们根据最初讨论的反馈将其设为可选加入。可选加入这一事实我认为真的让每个人都非常放心,还有我们会分享数据,所以这不是某种只有我们能访问的专有数据集,我认为这是另一个重要部分。

至于日常工作 --- 这要看情况。有时我们在做一些事情,我可以写一些代码,我可以花一两周时间写新代码,这总是很有趣...很多时候是一些原型,我预计团队的其他部分会接手并可能完全替换我写的东西,但我证明了"这是可能的。这可以工作",然后让团队来做真正的版本。

有时就是和很多人开会,审查设计,和他们谈论事情进展如何,他们在做什么,试图以有用的方式引导事情。即使是像有人为某个问题绞尽脑汁这样简单的事,我也可以说"哦,我们这里有个东西,我们已经几年没讨论过了。那可能会有帮助。"成为那种资源也非常有帮助。所以每天都不一样,但...能帮助别人的日子很好,能写代码的日子很好...总的来说,大多是好日子,所以很好。

Sameer Ajmani: 我要补充一点,Go团队奇怪地拥有大量非常有才华的人。我的意思是,我认为Google到处都有很多这样的人,但Go团队可能比其他地方多一点...然后Russ就坐在所有这些人之上,像是一个奇怪的才华横溢且全面发展的人的典范例子...[笑] 我总是试图找到他不擅长的地方,但到目前为止还没成功。

Cameron Balahan: Russ,你现在必须在你的标语里加上"奇怪的全面发展"了。

Angelica Hill: 如果我有幸在GopherCon上介绍你,我会说..."这位奇怪的全面发展的个人..."[笑] 好的,所以你有所有这些很棒的方式来众包想法、提案,当然你也有自己的想法和提案...但当涉及到"好吧,我们在做什么?"时,我们有所有这些有趣的途径,我们有所有这些可以改进的有趣事物...你是怎么 --- 我是说,你们是不是坐下来讨论所有冒出来的想法?你们一起做冲刺计划吗?实际的过程是什么,你们说"我们有所有这些很棒的想法,但我们实际上要用我们的时间做什么?"

Russ Cox: 规划更多是分布式的,三个不同的子团队负责自己的规划。所以有些事情来自提案过程之类的,我们会和人们交谈说"嘿,这看起来很重要。我们应该试着把它纳入进来",但这不是一种[听不清00:23:07.26]命令,我决定每个人下周要做什么之类的。我不认为那会有成效。

但总的来说,重要的是设定目标,这样我们就都朝着同一个方向努力。在Go最开始的时候,我们设定的目标是我们希望它能适用于我过去谈到的两种不同类型的规模,一种是生产规模,即扩展到大量机器、大量数据和所有那种计算机规模...另一种是人的规模,即扩展到有很多不同人参与的大型项目...即使你是一个5人的小团队,如果你使用开源包,现在你也在与数百或数千其他人一起工作。所以我们希望Go既能适应人的规模,也能适应机器的规模。

在Go目前的发展和生命周期中,很难做出改变。任何改变,尤其是语言改变 --- 你从编译器开始,但然后你必须修复编译器周围的所有工具,gopls,文档和所有那些东西。即使是库的改变 --- 我们也想确保这是一个我们想在未来十年支持的API,然后才会考虑重新审视它。

所以我们真的是在尝试做出我们会在10年内都满意的决定, 这是我瞄准的标准。所以,我们做什么的很多问题都基于"它是否服务于生产规模和人的规模的目标?"以及"我们现在对此满意吗?"因为不是暂时的,而是大约是永远的。所以对我们真的很重要,要对我们真正确定的事情说yes。

然后对于规划,有时会出现一些事情,比如某个外部或内部用途需要某些东西,我们会给予更多优先权...最近关于兼容性的工作就是一个例子,Kubernetes团队来找我们说"看,你们一直在以微妙的方式破坏我们,这些实际上并不违反兼容性政策..."你知道,你修复了一个bug。例如,典型的版本是我们有带前导零的IP地址。所以如果你说18.26.014 --- 比如,这是十进制的14,还是像八进制的12?结果所有BSD IP地址解析器都将其视为八进制。就像"哇,好吧,当我在Go中写IP地址解析器时我不知道这一点",我们将它们视为十进制。所以如果不同的工具正在读取它们,它们实际上对它的含义存在分歧。所以我们改为不允许前导零。

我们不能改变我们过去的内容,但我们可以说"我们不会再解析那个了。"现在至少如果我们接受一个IP地址,它对其他人来说就不会意味着不同的东西。但Kubernetes团队有理由担心可能存在一些配置写入了前导零并[听不清00:25:54.00]十进制,因为这是Go给你的...这就是我们过去常做的那种改变的一个例子,它阻止他们更新。所以我们做了大量关于兼容性的工作,我几年前在GopherCon上谈到过,使兼容性更加兼容。所以现在这些类型的改变,直到你也在go.mod文件中更新Go版本时才会触发。所以Kubernetes可以移动到更新的工具链,但保留他们的旧Go版本,然后仍然具有旧版本的那种bug对bug兼容性。这就是一个例子,我们提高了优先级,因为有一个团队来找我们说"看,我们无法获得你们的安全更新,因为我们无法更新到新的Go版本,因为存在这些微妙的破坏。"所以我们做的很多事情都是针对某些特定影响,而不是孤立地做。

Sameer Ajmani: 我要在此基础上补充说,Go团队有两个相互交织的规划周期。有我们的发布规划周期,这是公开的,每个人都看到像"嘿,下一个版本会包含什么?"工具团队有他们自己的IDE发布周期,安全团队必须处理安全发布等等。然后还有 --- 我们都是Google员工,所以我们是Google规划周期的一部分。通常有一个年度规划周期,我们做OKRs,即目标和关键结果...所以Cameron和我特别要与我们的Google利益相关者打交道,说"好,这就是我们正在做的工作及其原因。"

所以在Russ的兼容性例子基础上,Kubernetes是一个被每个主要云提供商和更多人使用的公共开源项目,但也有Google Kubernetes Engine团队,这是Google的一个主要的巨大收入产品。我们可以说"看,这是一个合作伙伴团队。为了他们能为客户服务 --- 这是Google的一个主要收入来源 --- 我们需要解决这个问题,以及Go如何改变自身,我们如何处理兼容性。"所以我们能够排列"这是Google的利益或Google对此的兴趣,这就是为什么这实际上需要我们这边的改变",我们能够从Kubernetes那里得到额外的利益相关者说"是的,这对我们来说确实非常重要。"但我们试图以一种不是专门针对Google或专门针对Kubernetes的方式进行这种改变,而是为Go生态系统进行一般性的提升。

所以我对兼容性工作特别兴奋,因为现在我们可以做出改变来改进Go。例如,我们最近对循环变量、range变量作用域和遮蔽所做的改变修复了Go语言中最痛苦的一个陷阱,如果没有一些兼容性工作,这真的是不可能的。所以当我们有一个特定客户或一个特定的紧急需求需要满足时,我们寻找这些双赢,并说"好,我们如何以一种能够普遍化并为整个生态系统带来价值的方式来解决这个问题?"

Cameron Balahan: 我要补充的另一件事是 --- 也许这在Russ和Sameer说的话中是隐含的,但我们有这三个团队,思考这些端到端解决方案是规划过程的另一部分。所以不仅仅是编译器和运行时,还有例如IDE团队,他们有gopls、Visual Studio Code插件等。我们与安全团队一起做的一些漏洞工作...所以去年,当我们引入漏洞管理或[听不清00:29:01.01]时,有几个不同的方面需要考虑。一个是命令行,有govulncheck工具,另一个是IDE,在那里漏洞会在你编写代码时出现,还有pkg.go.dev,在那里你可能想获取关于你正在考虑使用的依赖项的已知漏洞的信息...所以我们试图创建这些 --- 我们将使用所有这些不同的东西来创建一种我们发布的东西的连贯性,这额外强大。我们实际上发现Go社区会很快接受这些东西。他们都会使用 --- 而在另一个生态系统中,可能有各种工具可以用于同一个工作。在Go中,大多数用户会使用我们的东西,所以我们能够将他们引导到这些连贯的端到端解决方案中,我认为这使得每个人都更容易采用他们认为有价值的东西,比如更好的漏洞检测和修复。

Russ Cox: 我想补充一点,即使这三个子团队密切合作,你在日常工作中并不真的感觉到...Cameron解释了对于漏洞检查,显然安全团队和工具团队都参与其中...编译器运行时团队也参与其中,因为有关于从二进制文件中获取信息的标准库更改,有关于嵌入用于构建这个特定二进制文件的模块信息的链接器更改和编译器更改...所以这真的是一个全队努力。在日常工作中,我们不会听到 --- 你不会想"好吧,那个人在不同的子团队,所以我不能和他们交谈",或者诸如此类的事情。它真的感觉像一个连贯的团队。这是我们在Go中的一个真正优势。

我认为Go服务于两个不同但互补的目的。一个是实际上成为一个端到端的系统,我们控制它,我们可以 --- 如果我们决定"嘿,[听不清00:30:54.21]漏洞管理很重要",那么我们可以从编译器一直到IDE进行任何我们想要的更改,因为我们在我们的领域内拥有整个堆栈。

然后Go重要的另一个原因是它作为其他系统的一种例子,因为我们可以在Go中证明某些东西,因为我们控制整个系统,我们很容易进行整个系统的更改。然后我们可以说"哦看,我们做了整个事情。它工作得多好。这些事情真的很好用。这可能适用于其他系统",其他系统可以利用这一点。

当我们做goroutines时,Google内部的C++团队做了fibers,我认为我们已经发布了一些看起来很像goroutines的工作...最近,我们为Go模块代理做的校验和数据库,其他包管理系统也开始采用校验和数据库...所以Go作为一个我们都可以使用的生产系统很好。它也很好,因为我们可以树立一个榜样,我们可以展示"嘿,这实际上是有效的。"我们可以把它用作这些事情的测试场,证明场。

Sameer Ajmani: Go的这种领导作用,如果说有什么变化的话,那就是在加速。例如,当我们做漏洞时,Russ与Google内部的另一个团队合作,该团队正在标准化OSV,即开源漏洞标准。所以Go的漏洞方法的一个不同之处是,我们不仅包含了关于漏洞影响的特定包和版本的信息,甚至还包含了符号信息,比如哪些函数。如果你调用这些函数,那么你就会触发漏洞,如果你不调用这些函数,那么你就不会受到影响。我们使用这个 --- 再加上Go中的静态分析 --- 来过滤漏洞报告并对它们进行优先排序。我们可以消除40%与你的程序无关的报告,因为你没有调用受影响的函数。通过将其纳入OSV,这现在可以用于其他生态系统。如果我没记错的话,这也是新的CSV --- 抱歉,CVE 5.0标准。所以这是一个Go在安全和漏洞检查的特定领域的领导地位非常迅速地影响行业跟随的案例。

Angelica Hill: 从你的角度来看,这是否是拥有一个专门团队的核心好处之一,正如你提到的,Russ,真正的端到端,能够不断协作并确保如果在一个地方有变化,它不会产生负面的连锁反应,而且它真的会继续保持那种端到端的流畅一致性?

Russ Cox: 是的,绝对是。我的意思是,让Go感觉像是一个系统对我们来说真的非常重要。这并不是说在一个部分做某事会产生负面影响。我们显然不希望那样...但缺少这种情况并不是真正的标准。在一个地方做某事 --- 它需要实际渗透并在各处得到很好的支持。它需要感觉像是一个整体。它不应该是语言功能但例如gopls还不支持。所以如果gopls支持还没有准备好,或者还没有就绪,或者诸如此类,那么我们会推迟语言功能。我们不想发布只在生态系统的一部分工作的东西。我们真的希望它是一个整体。

所以随着Go的成长 --- 比如,在2009年Go的初始发布中,它只是一个编译器。甚至没有go命令。你只是运行像[听不清00:34:09.05]。它非常非常原始。现在我们从那里开始构建。首先我们有了Go命令,然后最终我们得到了所有围绕它的工具,诸如此类的东西,以及generate和test...然后现在我们有了IDE,以及所有其他 --- 比如,我们有VS Code Go和gopls,但然后所有其他IDE现在,或编辑器,它们都使用gopls...所以我们真的不断构建Go所涉及的内容。现在我们有了代理和校验和数据库...它不断增长,我们真的希望有一个连贯的系统。

Angelica Hill: 所以我很想了解一下 --- 无论是具体例子还是一般情况 --- 你是如何考虑开源社区和内部Go团队之间,Go团队内部,Go社区内部存在冲突的情况的?因为你有,正如我们多次提到的,非常有才华、非常投入的工程师,无论是在Go团队内部还是外部,他们都热爱Go...我相信有很多次实现X、Y、Z事物的正确方式,或者是否引入X、Y、Z功能是有争议的。这不是一个简单的是或否。我想知道你是如何处理这些决策点的。

Russ Cox: 是的,我的意思是,它并不像你想象的那么频繁出现...当它确实出现时,我认为那是因为人们有不同的观点还没有被摆在桌面上。所以当我在做提案过程阅读时 --- 我读了大量关于其他人如何运作流程的东西,以及诸如此类的东西...我发现John Ousterhout写的一份很棒的文档,标题是"开放决策"。你可以直接谷歌一下。他谈到共识驱动的过程时说, "如果你正确管理它,几乎总是可能直接达成共识。" 他说的引用是"如果一群聪明人都看同一个问题,拥有相同的信息,并且他们有相同的目标,那么他们很可能会得出相同的结论。"所以如果我们对结论存在分歧,我们需要做的是回到"我们是否有相同的信息,我们是否有相同的目标?"如果我们不同意,你追求的是什么目标,我追求的是什么目标?如果我们能从那里倒推,通常我们可以谈论目标。或者也许我有你没有的信息,我可以分享,现在我们有了相同的信息...我们试图在那个层面上工作,然后共识往往会随之而来。

所以我认为我们多年前学到的 --- 可能是在2014年左右 --- 当我们第一次尝试做别名时,效果真的不好,部分问题是我们实际上没有呈现我们拥有的所有信息,我们没有解释为什么它是一个重要的功能。所以我们撤回了它,然后那年11月在Gotham Go上我做了一个演讲,我称之为"渐进代码修复",以及关于一次一个包地进行大规模程序重构。特别是为什么类型别名对于实现这一点真的非常重要。没有类型别名你就无法做到这一点。

有了那个背景,然后我们做了类型别名,基本上那时没有反对意见。问题是我们没有分享足够多关于"为什么这很重要?"因为在非常大的代码库中,它超级重要。在你控制整个东西并且可以做一个大提交的小代码库中,情况就很不一样。所以再次,我认为所有的冲突最终都回到"我们是否有相同的目标?"和"我们是否有相同的信息?"我们可以通过分享更多信息来修复信息问题。至于目标 --- 我们可以说,"好吧,我们有不同的目标...但这些是Go项目的目标,所以这就是我们分歧的原因。"人们往往会对此没问题。就像"好的,我理解,我的目标与你不同。这就是我们不同意的原因。不是你没有听我说话。"所以我认为这些对我们在过去十年中学到的东西真的非常重要。

<font size=1 color="orange">

译者注:
在Go Changes--Russ Cox在GopherCon 2023的演讲 提到过

Gotham Go是在纽约举行的Go活动

Gotham即哥谭市,一般被认为是纽约的代称

</font>

Angelica Hill: 这是否也直接转化为 --- 这个问题可能是给你的,Sameer --- 你如何考虑内部冲突,或者也许是对解决已经被某种程度优先考虑的问题的方法的分歧,或者我们正在解决什么问题?这甚至是个问题吗?

Sameer Ajmani: 所以在Go团队内部 --- 这是一个非常赞的团队,我认为我们建立的解决问题的文化非常非常好。我看到冲突的主要地方更多是关于优先级,也就是人们对首先做什么是重要的存在分歧。一个人可能有一套他们正在努力实现的目标,或者正在进行的项目,他们受到一些时间限制,或者有其他人依赖他们...然后另一个团队成员依赖第一个人完成某些事情,他们觉得自己没有得到所需的时间。这只是一个有限资源的情况,通常我们需要保护人们的时间和注意力,让他们完成正在做的事情,然后他们可以转移注意力...而不是要求人们同时尝试做太多事情(我们过去犯过错误),这可能非常累人,会拖慢所有人和所有事情。所以我们试图让更多的团队致力于集体的、共同的目标...所以通常,这些更大的发布,像泛型、漏洞,确实倾向于将团队团结在一起,我们尽最大努力尝试组织每个人围绕这一点,所以至少我们有一个近期的共同目标,我们可以朝着这个方向优先考虑。

我们处理目标和冲突的另一个地方是当你超越Go团队,考虑更广泛的Google,以及Go团队如何在Google中立足,我们如何在那里确定优先级。好消息是,根据我作为领导的经验,Google一直是Go极好的管理者和赞助者...通常,Go团队非常受信任,可以为Go和Go用户做正确的事。我从未感到在Google受到压力去做任何对Go或Go用户不利的事情。我们有时会对什么是必要的,或什么应该优先考虑存在分歧,但这在一个大公司中是很自然的...通常,Cameron、Russ和我所做的艺术就是找到那个双赢的情况,在那里对Go正确的事和对Google正确的事是尽量一致的。

Angelica Hill: 我认为这引出了我的下一个问题,这个问题是给你的,Cameron,因为我们从你那里听到了很多,Sameer,关于优先级的困难...你是如何管理Go作为一种软件工程语言的产品的?所以我是一名技术产品经理,我负责管理一个产品, 但它是一个平台,它是后端数据基础设施...但你是如何管理产品或如何考虑Go作为一个产品的?

Cameron Balahan: 我知道,这很奇怪,对吧?我认为你不是唯一一个想知道这一点的人。我认为产品管理通常是一个非常特定于角色、公司和产品的事情。所以也许它总是有点模糊...但我试图弄清楚从优先级路线图、愿景的角度来看什么是最好的,以及我们为用户和Google提供的价值是什么,我考虑的是我在开始时提到的那件事,即这个用于生产级软件的高效平台。

所以我们知道这样真的很有效,Go用户和Google都从中获得了很多价值。我们以传统的产品管理方式看待市场,我们考虑产品选择生命周期,我们考虑我们试图在这里解决问题的角度是什么...结果发现Go在解决云时代的问题方面非常成功。大多数云基础设施都是用Go编写的,Go在这些领域做得很好。这也意味着在这个新时代,有很多不同类型的供应链攻击,Go在所有这些基础设施中扮演着关键角色,所以安全性真的很重要,我们也知道用户也会想到这个。

所以我考虑这个框架,我想"好的,我们在考虑什么?它如何进一步实现生产力和生产级的目标?我们如何确保我们从中创造出连贯的解决方案?"而且,它是否增加了我们希望它增加的价值,即我们的开发人员能够更快地获得价值,他们能够随着时间的推移降低他们的总拥有成本,他们的软件更可靠和安全...这是一些有助于用户更成功的事。

所以知道使命、工作和客户成功之间的这种路径是我可以用来思考其他一切的基本指导方针。然后补充一下Sameer刚才说的,我认为我很幸运产品是Go,因为 --- 嗯,首先,用户和社区真的很喜欢它。所以这个东西就继续自己成长。社区为它添加东西,在它周围构建库,为它找到新的用途...它只是自己拿起来用在新的计算范式中;你只会看到新的东西,"哦,它是用Go写的。太棒了。" 这一切自然而然发生。

对于Google内部而言,Google本身确实很尊重Go。我的意思是,Google做了很多很酷的东西,它的很多东西都有很多用户,诸如此类的东西都存在...但Go真的很特别。我认为Google认识到Go有多特别,以及Go用户对它的满意程度。我不知道你是否看过我们最新的开发者调查,我们的客户满意度达到了93%,我认为这在行业中是前所未有的。所以这很酷,我想每个人都认识到这一点。这也让我的工作变得更容易。

Angelica Hill: 当然。Gopher们热爱Go。所以我很想听听 --- 我们已经谈了一些过去的事,我们也谈了一些当前的流程和现状...我很想听听你们每个人对未来的期待,无论是即将到来的事情,还是当你们思考Go的未来时你们在想什么,你们对什么感到兴奋,你们在思考什么有趣的问题。什么让你们感到好奇?什么让你们思考有趣的问题?也许我们从你开始,Russ。

Russ Cox: 当然。实际上我对Go 1.23非常兴奋。我最近一直在写大量的代码,能够使用新的迭代器和新的range循环真是太棒了。我的意思是,能够编写适合range语句的自定义迭代器 --- 这真的有点改变了我写很多代码的方式。能够抽象出诸如数据库扫描之类的东西,以及那些类型的东西真的非常有帮助。所以我迫不及待地想让所有这些都上线,这样其他人也可以写那些类型的东西。

从长远来看,我在思考的是 --- 我认为这是正确的说法 --- 就是开源的整体可持续性。因为我们从像xz攻击这样的事情中看到 --- 我们多年来一直知道关键的东西严重缺乏资金,这为坏人创造了一个非常容易的机会,真的可以在这些低层次上造成任意的伤害。

我问了一屋子来自不同公司的资深人士,他们认为xz攻击花费了多少钱。普遍的共识是"也许100万或200万美元"。而也许100万或200万美元就几乎可以在互联网上的每台机器上获得SSH shell --- 这相当不错。这是相当好的投资回报率。所以我们需要想办法让这些攻击变得更加困难。我们不能继续在开源中做我们正在做的事情。所以这是我们作为一个行业在未来十年必须解决的有趣的疑问。

<font size=1 color="orange">
(译者注: xz攻击指的是2024年3月份发现的Jia Tan长达几年潜藏底层开源项目,添加恶心代码事件)
</font>

Sameer Ajmani: 两件事...一是我们谈到了供应链安全和漏洞 --- 我实际上认为在这方面还有很多可以做的。Go生态系统的一个区别特征是它的统一性。每个人,在大多数情况下,都在使用go命令来构建,使用go modules来管理依赖...这是一个巨大的杠杆。这意味着我们可以做一些事情,比如当有人对上游包进行更改时运行测试;你可以运行一些依赖测试的样本,看看在更改被提交或标记为下一个版本之前是否会破坏任何东西。你可以想象,如果我们能够大规模地做到这一点,我们可以大大降低整个生态系统中破坏性变更的比率,这将为每个人降低成本。不仅会降低成本,而且如果发生的破坏性变更更少,那么更新到最新版本就会变得更容易和更便宜。这不仅使得跟上功能变化变得更容易,而且还可以更容易地修复漏洞。所以如果你有一个有漏洞的依赖,而你知道更新不太可能破坏你的代码,因为生态系统的破坏性变更更少,那么漏洞的持续存在就不太可能了。所以如果有一个供应链攻击,就像Russ刚才提到的,我们必须能够更快地大规模修复。这些都是Go生态系统的统一性以及构建系统和模块系统特别能够实现的,我认为这在大多数其他生态系统中是不可能的。所以我觉得这很令人兴奋。

另一件事 --- 我相信Cameron也会谈到这一点 --- 就是AI正在吞噬我们所有人的生活,对吧?每个人都在谈论AI,询问AI...好消息是我们已经思考Go和AI有一段时间了。甚至早在去年年初或更早之前,我们就在思考"嗯,Python用户真的很喜欢Go,很多人确实采用了Go,而Python被用于AI...所以这里有什么联系吗?"我们的结论是"不太可能",在某种意义上说,数据科学家喜欢Python是因为它是一种非常棒和非常符合人体工程学的语言,非常高效,在你的笔记本中工作得很好,而且有这个庞大的生态系统,有非常丰富和优秀的库。我们没有想要从Go那里去竞争这一点。但是现在,随着越来越多的大公司、企业和初创公司想要在AI模型之上构建系统,他们想要构建基于AI的生产级、可信赖、可靠的系统。现在我们进入了Go的领域,对吧?

所以在我脑海中的问题,我们都一直在讨论的是,"那个转变的时刻是什么?",当你从比如说,在Python中进行原型设计,证明概念和想法,然后你说"好的,现在我们要认真了。我们想要构建一个产品,我们想要构建一个系统。我们想要构建一个服务,我们想要构建使用AI的基础设施,并有适当的检查和平衡来处理AI的不可靠性和幻觉。"如果我们希望这是用Go来实现,那么就有一个转变的时刻,在那里"好的,现在[听不清 00:49:15.26] 这看起来像什么,我们如何促进这一点?我们如何让Go成为构建生产AI系统的语言?我认为这是下一个大前沿,我们将看到对此的大量需求,我认为Go是一个非常适合的选择。

Cameron Balahan: 是的,Sameer有点说了我想要说的话,我本来想说的是,我对Go的增长感到兴奋。编程语言的采用本质上是一个缓慢的过程。没有人会回去重写已经工作的东西,我们也不希望这样...如果你已经有大量用一种语言编写的服务器,你可能会用那种语言编写下一个...所以引入一种编程语言然后让它被采用 --- 这是一件大事,需要很长时间。只是看到Go的有机增长,特别是近年来,就像我说的,社区喜欢它,它就不断自我持续发展...我认为现在已经达到了一个门槛,我看到它可能会更快速地增长,或者至少在更多地方找到它。我认为部分原因可能是以特定的方式与AI前沿有关,但它实际上更普遍地与新的计算范式有关;当这些出现时,这些就是写新代码的机会。也许新公司出现了,他们必须选择一个技术栈,他们可能会使用云,他们可能会关心生产力和他们能多快地推出产品,他们可能会关心长期的总拥有成本,以及产品的安全性和可靠性,他们会发现Go非常适合所有这些事情,而他们可能在很久以前学过的其他语言,或者在早期看到过生产中的语言并不那么适合。这是非常令人兴奋的,因为Go真的很适合。所以我真的很兴奋看看会发生什么。一般来说,就是增长。所以AI是作为增长的贡献者。

然后你问到了一个担忧,或者类似的东西...我可能不担心,但只是在思考AI。我想知道这一切看起来是什么样子。这显然非常有趣,我认为特别是在软件开发生命周期中,有机会削减低效率,使工作更有成效...有时候虽然看起来其中一些被夸大了,我不知道实际的真相在哪里,但我有兴趣看看这将如何发展。更强大的代码完成实际上会对软件工程更普遍地产生什么影响。

所以正如Sameer所说,我们密切关注这一点,因为理解我们所处的市场和我们的用户想要什么是很重要的。我们希望能适应。我们希望为我们的用户提供所有让他们满意的东西,比如生产力和其他东西。所以我会说总体增长,但想知道AI在未来会如何影响我们的整个行业。

Angelica Hill: 当然。我还有一个最后的问题,这更多的是关于你们如何思考Go及其发展。我知道,比如Sameer,你提到了Python在这个领域的角色,那不是Go的领域,但这是...我有点好奇在你们的脑海中 --- 任何人都可以回答这个问题 --- 是关于让Go在它当前所在的领域成为最好的,真正使那个,正如你所说的,Sameer,那个房子成为你能建造的最强大的房子,用最好的材料?还是关于建造一个房子、一条船、一个平房和一架飞机...?[笑] 或者更多的是 --- 请原谅我如果我用这个解释让你们迷惑了..."好的,这个房子已经足够好了。让我们现在用Go来建造这架飞机",真正进入Go现在不在的领域?

Sameer Ajmani: 所以我将这个问题具体化为现有房子的机会与其他机会。比如说,让我们看看云。Go是一种非常棒的语言,用于构建云应用程序、多线程服务器、进行大量通信。我听到的所有估计都指向,可能在云上的大多数工作负载仍然不在云上。所以还有巨大的未来来构建可扩展的软件和基础设施,这些需要可靠、生产就绪和高效,以及Go所具备的所有特性。所以我认为我们现有的Go基础仍然非常重要,它仍然需要大量投资才能做得很好。

同时,正如Cameron指出的,软件工程和软件开发正在转变。我们需要关注它是如何变化的。所以我认为我们不知道 --- 我记得在你的笔记中看到,你问"那么ML呢?前端呢?"我们甚至多年前就看过Go mobile...我们尝试不要仅仅根据什么是热门就追逐下一个新机会。我们试图有选择性。例如,当所有的加密和挖矿东西都很热门时,一些加密人采用了Go,Google的人问"哦,我们看到[听不清 00:54:56.19],我们基本上说"不,我们很好。我们不需要追逐那个潮流。"但是对于供应链安全,我们看到了做一些真正与众不同的事情的机会,这与我们现有用户想要的东西非常一致。

所以对于AI --- 再次,我们不是试图追逐数据科学家和迭代模型开发的Python用户。我们关注的是那些在生产中大规模构建的人 --- 他们将不得不处理AI,处理将AI整合到他们现有的系统中,他们将处理模型、安全性和可观察性。那么我们如何为他们服务呢?所以有一种方法可以利用我们现有的用户群,他们现有的关注点,同时也思考"好,他们的需求如何扩展?Go用户的工作将如何改变?"所以它既是构建使用模型的系统,也是他们自己使用AI生成Go代码或理解他们的Go程序。所以我想这就是我思考我们的工作如何改变的方式,如果你是一个普通的Go用户,你的世界如何改变,我们Go团队如何促进这种改变?

Angelica Hill: 所以如果gopher获得闪亮的新ML法拉利,你们将不得不确保你们的Go房子有一个适合那辆ML法拉利的车库?

Sameer Ajmani: 我喜欢它。这是一个完美的比喻。

Cameron Balahan: 我只是想补充一点 --- 别忘了还有整个Go社区在Go之上构建。Go团队本身不能构建所有那些平房和那些汽车和所有那些东西...只需确保他们能够构建他们需要构建的东西,以继续 --- 保持Go在人们需要高效地构建他们的业务、构建软件、构建他们需要构建的东西并且达到生产级别的前沿...这是思考的重要部分,就是有一整个社区在上面。

Angelica Hill: 还有什么最后的想法吗?我们即将转向不受欢迎的观点,但我想确保如果你们有任何最后的想法或你们真的很兴奋要与我们的Go Time听众分享的事情,我给你们这个机会。

Russ Cox: 当然,我有一个想法。去telemetry.go.dev并启用遥测。

Angelica Hill: 太棒了。好的。

[音乐淡入]

Sameer Ajmani: 多年前 --- 嗯,可能我对Go最大的贡献实际上是context数据类型,每个人都必须处理它侵入他们的函数签名...Russ和我一起做了最初的设计,但我做了大部分的编写和推广。我们得到了很多反馈说"啊...!难道没有更好的方法吗?"我不受欢迎的观点是context很好。它实际上很好地完成了它的工作,考虑到你必须处理多线程请求处理程序、goroutine、截止日期和超时,以及请求[听不清 00:57:54.01]值,它所做的事情是非常微妙和棘手的...它基本上就是工作。而且实现足够简单,我们能够随着时间的推移对其进行优化,而且...是的,context滥用的风险并没有成为我们真正担心的巨大、普遍的问题...而且在大多数情况下,Go开发人员似乎正确地使用它,我对此很感激。

Angelica Hill: 这是一个很棒的不受欢迎的观点。接下来,Cameron或Russ,你们有什么不受欢迎的观点想要分享吗?

Cameron Balahan: 当然。所以我一直在想这个...其中一个,我想,我之前在某些场合分享过,那就是我真的很喜欢Go的错误处理。我真的很喜欢。所以当人们对此感到失望时,我总是感到困惑。但我也在想,关于非Go的不受欢迎的观点,我想我会选择的是,我认为那些酸味软糖虫和软糖熊之类的东西比巧克力或类似的东西要好得多。我不知道,你在做鬼脸,我在想你可能认为这是一个可怕的观点,但这是我真的想说的。

Angelica Hill: 为什么...?

Cameron Balahan: 我不确定如何回答为什么。它只是看起来更好。

Angelica Hill: 好的。是因为口感吗?

Sameer Ajmani: 它只是完美地结合了甜味和酸味。

Cameron Balahan: 是的,你知道吗?就像...Russ,你同意吗?

Russ Cox: 我完全同意。现在你在这个语境中提到了这些,我觉得我们需要让人做一些小小的软糖地鼠。

Cameron Balahan: 那是个好主意。

Russ Cox: 我们需要想办法让这件事发生。

Angelica Hill: 哦,天哪...呼叫任何在食品或糖果加工公司工作的gopher...在Gopher Slack上给我们发消息。联系Go Time。我们会尝试让它发生。那会很棒。

Cameron Balahan: 我会很喜欢的。

Angelica Hill: Russ,你还有其他不受欢迎的观点吗?

Russ Cox: 当然。每隔几个月我就会在Reddit或其他地方看到一些东西,问"为什么Go还没有摆脱空指针?"所以我不受欢迎的观点是空指针没问题。它们是计算机的一个基本事实,就是内存可以被置零。那些试图隐藏这一点的语言,一般来说 --- 总有一些聪明的方法可以得到一个nil,或者更糟,未初始化的内存,因为他们非常确定它永远不会被看到...而空指针错误基本上是最容易处理的错误,因为在它崩溃的地方,它会打印出程序正在做什么的整个堆栈跟踪...你去那一行,或者你看看父帧,你就会说"哦,这就是你怎么在那里得到一个nil的",然后你基本上就完成了。所以它们是我最喜欢的错误,因为它们就坐在那里,向你准确地显示发生了什么,然后你修复它。

Angelica Hill: 我很好奇看看这是不受欢迎还是受欢迎,鉴于你非常连贯地解释了为什么它们是有帮助的,我们必须保留它们。[笑]

非常感谢你们的不受欢迎的观点。我想以一个快速的 --- 如果人们有兴趣,如果他们想要更多地参与Go,如果他们是Go的新手,他们说"好的,我听了这个播客。这个Go东西听起来很有趣",你们对他们的建议是什么?他们如何参与?他们应该做什么?

Russ Cox: 我会说Gopher Slack,邮件列表,问题追踪器...如果你去go.dev并滚动到底部,有一堆联系链接,任何一个都可以。

Angelica Hill: 很好。我会在这一集的描述中链接你们提到的链接,所以无论你在哪里听这个,你都可以进入这一集的描述,你会看到一个很好的链接列表供你点击。

Cameron Balahan: 当然还有聚会,会议,其他的社区活动...外面有很多东西,它们都非常令人兴奋,是一个真正好的社区。所以这些也是人们的选择。

Angelica Hill: 如果你有任何问题,Gopher Slack是我们所有人都在的地方,所以请加入那里。那里很有趣。请随意加入伟大的Go社区。非常感谢你们两位。我真的很感谢你们的时间,感谢你们今天加入我们。祝你们度过美好的一天。