RSC的交棒

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年加入了团队。

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

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的系统。

(译者注:

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

Codecov:

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

SolarWinds:

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

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

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项目的目标,所以这就是我们分歧的原因。”人们往往会对此没问题。就像”好的,我理解,我的目标与你不同。这就是我们不同意的原因。不是你没有听我说话。”所以我认为这些对我们在过去十年中学到的东西真的非常重要。

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

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

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

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 — 这相当不错。这是相当好的投资回报率。所以我们需要想办法让这些攻击变得更加困难。我们不能继续在开源中做我们正在做的事情。所以这是我们作为一个行业在未来十年必须解决的有趣的疑问。

(译者注: [xz攻击](https://www.aqniu.com/industry/103405.html)指的是2024年3月份发现的Jia Tan长达几年潜藏底层开源项目,添加恶心代码事件)

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社区。非常感谢你们两位。我真的很感谢你们的时间,感谢你们今天加入我们。祝你们度过美好的一天。

20241004

帮我整理这一期英文播客，翻译为通顺的中文，请保留完整内容，不要删减，谢谢！

Russ Cox on passing the torch

拉斯·考克斯谈火炬传递

本篇内容是根据2024年9月份Russ Cox on passing the torch音频录制内容的整理与翻译,

在本集中，我们将采访 Russ Cox，他于 2008 年加入 Google Go 团队，自 2012 年以来一直担任 Go 项目技术负责人，谈论他将退后一步并将领导权移交给 Austin Clements，他也将加入我们！我们还有 Cherry Mui，她将接替 Austin 之前的角色，担任“Go core”的技术负责人。

https://mp.weixin.qq.com/s/7YXvcXd50fz5TYk5slZ8gg

Angelica Hill: 你好，欢迎来到 Go Time。我真的非常兴奋今天的节目！今天我们邀请到了三位非常棒的嘉宾，他们会谈论一下最近在 Go 团队中发生的领导层变更。我邀请到了 Russ Cox，他早在 2008 年就加入了 Go 团队，并自 2012 年以来一直担任 Go 项目的技术负责人。他会谈谈自己如何从这个技术负责人职位上退下来，并将权力交给我们非常优秀的 Austin Clements---Austin 今天也在现场，我对此非常激动！他们会聊一聊这次过渡对他们意味着什么，以及他们如何看待接管 Go 团队并将其带入 Go 的新篇章。

我们还邀请到了 Cherry，她接任了 Austin 之前的职位，成为 Go 核心团队的技术负责人，这可是 Go 生态系统中极其重要的一部分。所以今天我们真的非常幸运能有她加入。好了，话不多说，Russ，欢迎再次来到节目。我非常高兴你能来。你最近怎么样？

Russ Cox: 谢谢，很高兴再次回来。我今天挺好的，也非常激动能来到这里。

Angelica Hill: 看起来你对退下来这件事适应得很好啊，毕竟你刚才提到你今天可以睡个懒觉。真是幸运啊……

Russ Cox: 其实我今天在度假，但我特意抽了一个小时的时间来参加这个节目，所以我对此感到很兴奋。

Angelica Hill: 太好了，真的非常感谢你在休假期间还能抽空来 Go Time 跟我们相聚。接下来我们欢迎 Austin。你好，Austin。

Austin Clements: 你好。

Angelica Hill: 你大约在 10 年前加入了 Google 的 Go 团队，对吧？

Austin Clements: 差不多是这样。

Angelica Hill: 所以你已经在这里工作了一段时间了。

Austin Clements: 嗯，没错。

Angelica Hill: 今天感觉怎么样？

Austin Clements: 我很好，谢谢。

Angelica Hill: 我们很高兴你能来，期待着深入了解更多。最后但同样重要的是，Cherry，你怎么样？

Cherry Mui: 很好，今天你怎么样？

Angelica Hill: 我也很兴奋能更好地了解你们两位。我还没有太多机会深入了解 Austin 和 Cherry，所以今天我们不仅会聊你们的工作，还会聊聊你们作为普通人的一面，当然也包括你们作为 Gopher 的一面。既然我对你们还不是特别了解，而且我们也希望所有可爱的 Gopher 们能更好地认识你们，毕竟你们现在处于这些重要的角色中，所以我想给你们两位一些时间，聊一聊你们自己，聊聊你们是如何进入 Go 的，怎么来到今天这个位置的……有趣的爱好和趣闻也是非常欢迎的。如果你愿意的话，随意介绍你自己给 Go Time 的听众。也许我们可以先从你开始，Cherry。

Cherry Mui: 我是在 2016 年加入 Go 团队和 Google 的。从那时起，我主要从事编译器、运行时和工具链相关的工作。我也做过其他事情，但大多与编译器和运行时相关。我现在担任 Go 核心团队的技术负责人已经两周了。

在此之前，我是布朗大学的研究生，学习化学……我是如何来到 Go 的呢？当我还在学校的时候，有个朋友---那时候我基本上是把编程当作一种爱好，玩代码只是为了好玩。我喜欢玩编译器和操作系统，所以我花了一些时间在 Plan 9 编译器和 Plan 9 操作系统上进行一些黑客式的实验。我一个朋友告诉我，有一种新的编程语言叫 Go，它和 Plan 9 有不少关系。“你一定会觉得这很有趣。”于是我尝试了一下，结果确实非常有趣。我发现这是一种非常酷的语言，我几乎马上就被说服了，觉得自己很喜欢 Go。我的朋友是对的，我确实喜欢 Go。他还说服我去 Google 和 Go 团队工作……所以基本上就是这样，我来到了这里。

Angelica Hill: 哇哦！看来我们都应该非常感谢这位朋友。听起来他是个非常好的朋友啊。

Cherry Mui: 是的，是的，他确实是。

Angelica Hill: Austin，你呢？

Austin Clements: 你好。要回答是什么让我接触到Go语言的，我得回到差不多20年前。我是在将近20年前认识Russ的，当时我们在麻省理工学院（MIT）一起研究生学习。然后到了2009年，我疯狂地想找一个实习机会，因为我一直没有好好规划……而那时Russ已经在Google工作，参与Go语言的开发了。他说：“嘿，我们在做一些很酷的东西，聊一下吧。”那时候Go还没有公开发布。所以我就见了Russ，他向我描述了Go语言的核心设计和理念，从那时起我就被它吸引住了。

实习结束后，我继续攻读我的博士学位，直到大约10年前，我正式加入Google，直接进入了Go团队……自那之后，我就一直在这儿工作。2017年，我成为了Go编译器和运行时的技术负责人，而现在我正在交接这个职位。

我从一年级开始编程。我热爱编程，热爱编程语言，也喜欢不同的编程语言如何从不同的角度塑造你的思维……我曾在MIT教授了好几年Scheme语言(译者注: 函数式编程语言，是Lisp的两种主要方言之一,另一种是Common Lisp)，我非常喜欢看到学生们那种新的理解火花，尤其是那些已经编写C语言类代码多年的人……但Scheme对他们来说是一种全新的思维方式。而Go语言不仅带来了熟悉感和实用性，还推动你以更新、更好的方式、更有结构的方式思考。所以当Russ向我介绍Go时，我心想：“这真的很棒。”

除了编程，我还非常喜欢抹茶，十多年来我一直在完善我的抹茶拿铁技巧。我刚从日本回来，期间每天至少喝了两种不同形式的抹茶。我还喜欢智能家居设备。疫情开始时，我有点疯狂地购买了一堆智能家居产品，现在我的网络已经乱成了一团，我确实需要找时间整理一下。我也喜欢中世纪现代建筑风格（MCM）。我们住在一栋MCM风格的房子里，刚刚完成了一次大规模的装修，我们对此非常自豪。

Angelica Hill: 这真是太棒了。不过我有点小抱怨。我前几天买了抹茶粉，我非常喜欢抹茶拿铁，但我住在纽约，拿铁真的很贵，我说实话，还没有经济能力每天都买抹茶拿铁。我还没达到那个生活水平。我在努力，但还没到。所以我从Whole Foods买了一些抹茶粉，回到家后，我加了一点热水搅拌了一下，倒进牛奶里……结果味道太难喝了，完全不是我期待的抹茶拿铁。所以，我得向你讨教一下如何做出理想的抹茶拿铁。我相信其他Go Time的听众中也有喜欢抹茶的人，他们可能和我一样，为抹茶混合问题困扰，抛开Go编译器的问题不谈，抹茶混合更重要。

Austin Clements: 其实有几个非常关键的点。首先，你得从好的抹茶粉开始。抹茶粉的品质差异非常大。如果你上网搜一下，你甚至会发现一些网站上有评测和品尝笔记。就像品酒一样，抹茶的品质差异很大。即使是非常高质量的抹茶，不同品牌和产地的味道也不同。所以你还得找到适合自己的抹茶。

再者，冲泡的方式也很重要。我强烈建议先把抹茶粉过筛，因为你不想要粉末中有结块。所以我总是先筛一下抹茶粉。搅拌时，使用正确的工具也很重要。你需要用chasen，就是那种竹制的搅拌器，因为抹茶粉很容易在水中再次结块。搅拌时，你要前后搅动，像画W形，而不是画圈搅拌。你可以通过抹茶的颜色来判断质量好的抹茶粉，它会呈现翠绿色……并且你应该能在整个碗上打出一层薄薄的泡沫。

最后一个重要的点是要适当加点甜味。因为纯抹茶粉通常味道比较苦。我喝过一些不那么苦的抹茶，但大多数情况下它还是苦的。如果你稍微加点甜味，实际上能让抹茶的细腻风味更加凸显，同时压制住苦味。你可以直接在抹茶里加点糖浆，或者像日本茶道那样，抹茶本身不加甜味，但旁边会配上非常甜的红豆泥或者其他甜点，这样搭配着吃。

这些就是我的小建议。

Angelica Hill: 太感谢了。不仅是技术领袖，还是抹茶领袖，带领Go社区进入更好的抹茶时代。我已经准备好了。所以我听下来就是说我要做Austin推荐的完美抹茶，然后---虽然大家看不到，但如果你们去看Cherry的照片就会发现---Cherry有着最漂亮的绿色头发。所以我听到的是我要把头发染成绿色，然后喝Austin支持的美妙抹茶。Go社区的未来真是光明。我对此非常兴奋。非常感谢，我真的很感谢你愿意让我更好地了解你……

Russ，现在我想和你聊聊。我想了解一下你决定卸任Go技术负责人，然后把这个职位交给Austin，以及把Cherry安排到Austin以前的角色的过程。我想听听这是如何发生的，以及我们是如何走到今天---现在大概已经过了一个月左右，或者可能更久，具体看这一集播客什么时候播出---你们都担任了新的角色。

Russ Cox: 其实Austin赢得了抹茶比赛，所以就这么定了。

Angelica Hill: 就这么定了。 [笑声]

Russ Cox: 说得认真一点，不管你在什么职位上，你都要时刻考虑如果你不能再胜任这个职位，谁会接替你。所以我们在Google内部讨论了很多年，每个团队成员如果离开了，谁会接替他们的工作。对于我来说，我一直觉得Austin是接替我领导Go项目的合适人选。显然，我们的关系非常深厚，但Austin在对待计算、Go语言和整体技术的方式上有很多与我们最初为Go设定的目标一致的感受……所以对我来说，这一直都是一个非常合适的选择。其实这就是我一开始招募Austin加入Go项目的原因。

所以对我来说，Austin最终接管是毋庸置疑的。而在某个时刻，我意识到不仅他是合适的人选，而且他已经准备好了，Go项目也会因此受益。毕竟我已经正式担任Go技术负责人12年了。在那之前的几年里，Rob曾经介绍我们时说他和我是共同技术负责人……我都没注意到他是什么时候开始这么介绍的。而我已经为Go项目工作了16年。

12年是一个项目由同一个人领导的很长时间了……任何时候一个领导人在任职太长时间，事情都有可能变得停滞。我是不是真的想再做12年呢？可能这样对我或对项目都不好。到那时候，Austin和Cherry可能已经厌倦了，去寻找新的、更广泛的角色了。

所以让我退居幕后，让他们走向前台，承担更大责任，发挥他们的长处，这对项目是有意义的。而我可以在后面提供支持，确保他们需要的任何帮助我都能提供，作为后盾支持他们。

对Go社区来说，这也是好事。在Go的早期，Rob是领导者，围绕他有一点点“个人崇拜”的现象。然后Rob把领导权交给了我，我觉得在过去的12年里，类似的事情也发生在我身上。人们认为有些事情只有我能做，或者只有我的想法是解决问题的唯一正确方式……但是这种情况很不幸。这不是你想要的技术项目发展的方向。

这不仅仅在Go项目中存在。你可以在其他项目中看到这种现象---我就不点名了---但你完全可以看到那些项目的领导者已经领导几十年了。有些项目的领导人已经领导了几十年，你看看他们现在在做的事情，你会觉得“你们有点落伍了，没跟上时代的变化。”我不希望这种事情发生在Go身上，也不希望发生在我身上。我认为从时间到时间更换领导者，引入新的视角和领导是合理的。

还有一点很重要的是，技术负责人实际上是一种服务角色。这个职位不仅仅是个荣誉头衔，然后你就可以继续过自己的日子。它需要大量的工作。我觉得让不同的人以不同的方式承担这个角色，并对社区和团队带来不同的服务方式是有意义的。

Angelica Hill: 你刚才提到了不同的领导者能够带来不同的变化，社区中可能会发生一些显著的转变，尤其是在技术和社区管理方面……Austin，我想跟你聊聊这个话题。首先，对于那些不太了解的人来说，Go团队的技术负责人到底是做什么的？这个职位的职责是什么？我想听听你的看法，同时也想了解你个人对Go语言技术领导的看法。

Austin Clements: 是的，当然可以。我非常喜欢Russ对技术负责人的描述---这是一种服务角色。我相信技术负责人是把项目凝聚在一起的粘合剂。我坚信伟大的工作来自于不同的视角，而技术负责人的工作是促成这些视角的汇聚，把它们融入到一个连贯的整体中。如果你接纳了每一个想法，最后你可能会得到一团混乱。但如果你只接纳自己的想法，你同样不能提供好的服务。

作为项目领导者和技术负责人，我拥有更广阔的视角，我认为我的责任是专注于那些需要跨领域解决方案的问题，因为我拥有独特的视角。但我并不一定对每个领域都了解得很深，所以其他人专注于需要深入解决的领域问题是非常重要的。

这两者都很重要，而我认为我角色中的一个重要部分就是将这些视角结合起来，确保它们被听到、被看到并加以利用，最终整合成一个连贯的整体。

Angelica Hill: 当你考虑自己想要产生的影响时，无论是在技术上还是在Go社区中，你有哪些首要的想法？我知道这是一个你刚刚接手的新角色，但就一些初步的想法而言，你希望看到哪些改变？你如何看待自己的角色，以及如何在Go社区中留下自己的印记？抱歉，Russ，这已经不是你的角色了。现在是Austin的时代，这真的很令人兴奋。我认为这是一个积极的机会---结束了一个美好的篇章，开启了Go领导的新篇章。就像Russ你提到的那样，领导角色的变化是一章又一章的。我很想听听你对此的看法，你的目标是什么，你如何思考这个问题；你的期望是什么？

Austin Clements： 是的，当然。首先我要说的是，Go 语言的稳定性非常重要。所以我没有计划进来后完全颠覆现有结构。[笑声] 就我现在在思考的事情来说……我们常说 Go 是为大规模工程设计的，也是为了应对扩展而设计的。我接任这个职位时，心里一直在想的是，如何在不失去 Go 语言的简洁性和易用性的前提下，让 Go 本身的开发能够扩展。这其中有技术层面的问题，也有人员层面的问题。

在技术层面，比如我们现在开始看到新的诊断策略带来的收益，有同事正在推动这方面的工作。我们基本上认识到，Google 的 Go 团队没有足够的资源来构建所有人们想要和需要的运行时诊断工具。所以我们在想，如何创建一个平台，让人们可以自己构建工具？这是一个让 Go 本身开发得以扩展的技术方法。

在人员流程方面，我也在思考很多如何更好地与我们这个了不起的开发者社区沟通，并利用他们的力量。如何提高我们的透明度？如何更好地接受贡献？如何更好地留住优秀的人才？如何在保持 Go 项目长期稳定的同时，提升 Go 语言的工程能力？另一个我现在特别关注的是从大规模工程的角度来思考问题。

Go 的一个核心原则是编程应该是有趣的。我坚信用 Go 编程依然很有趣，但我也认为，Go 语言的稳定性带来了一些代价---其他语言在进行大量实验，而其他语言在某些地方确实做得更好，它们变得更高效、更有趣。我认为 Go 从来不是为了模仿其他语言，但我们可以从最近几年其他语言的发展中学到很多东西。

Go 开启了更多系统编程语言的发展，探索了编程语言的更多可能性。我认为很棒的一点是，我们的 Go 语言处于稳定性较高的那一端，而其他语言则愿意大胆探索。我觉得我们可以借鉴其中一些最好的想法，然后带回到 Go 语言中，让它保持新鲜感。因为编程的乐趣和生产力的标准是不断变化的，它们并不是固定不变的。我认为我们需要跟上这些变化，需要不断学习和探索。

在工程扩展方面---我一直在思考如何设计能够扩展的系统。我博士论文的主题是软件 API 设计接口与多核扩展性之间的形式关系。最近我也在深入思考 Go 的性能问题。我们花了很多年努力让所有方面都提升性能，但现在这方面的机会越来越少了。显然，我们会继续努力，但随着时间推移，这变得越来越困难。

因此，我认为我们正在进入 Go 性能和扩展性的一个新阶段，我们需要给用户更多的机制来进行明确的性能优化。但我也深信，Go 中的性能优化必须是渐进和可组合的。这样，工程师们可以只在关键地方投入更多精力以降低资源消耗，而不必在每个地方都付出高昂的工程代价……他们也不需要时刻担心系统在演变过程中性能优化的影响。

我们对内存分配的一些实验其实是一个很好的例子。几年前，我们推出了基于 Arena 的显式分配的实验支持，但没有继续推进，因为它并不是可组合的。你必须非常小心地跟踪分配的方式，而这些细节往往会从使用它的 API 和库中泄露出来。所以它是渐进的，但并不是可组合的。例如，我们现在正在实验一种新的 Arena 分配变体，它是可组合的，基于这样的原则：工程师在进行性能优化时可以在代码中添加一些注释，然后暂时不用再担心它。

当然，如果做错了，性能会退化，否则我们就可以自动完成了。但如果你做错了，或者系统随着时间的推移发生了变化，它会优雅地退化，这也意味着你可以定期查看这些注释，看看哪里需要重新调整。而且希望相关工具可以告诉你：“你可能需要再次查看这里，看看发生了什么。”

所以这些是我目前在思考的一些事情，虽然还有很多其他想法，但这些是我最近一直在想的几个主要问题。

Angelica Hill： 现在我们来聊聊 Cherry，你也有一个非常令人兴奋的新角色。首先，我想从基础开始---当我们说你接任了这个角色，成为 Go 核心团队的技术负责人时，这到底意味着什么？对于那些可能不太了解的人来说，Go 核心团队是什么？

Cherry Mui： 好的，当然可以。之前我们有独立的编译器运行时子团队和一个独立的 Go 发行子团队。我记得有段时间，发行子团队也被称为其他名称，比如开源项目团队，或者 Go OSP 团队，或其他名称，因为职责有所变动……但主要还是与 Go 的发布有关。我想是在疫情期间，部分原因是团队成员的变化，以及其他原因，我们决定组建一个更为整合的团队，叫做 Go 核心团队。它基本上包括了编译器、运行时、工具链和 Go 发行的各个方面。由于语言本身、编译器工具链、运行时和 Go 发行都处于 Go 语言的核心位置，其他部分如工具、IDE 插件、平台、云集成等都是建立在这些基础之上的……所以我们称这个团队为 Go 核心团队。它是这样来的，我想。

Angelica Hill： 你对你新的角色感觉如何？我想问一个类似的问题，就像我问 Austin 一样。你是如何看待你现在负责的这个领域的？有哪些让你感到兴奋的事情？你大概上任一个月了，对吗？大约一个月？

Cherry Mui： 不，只有两周。或者如果算上之前 Austin 休息的那一周，可能是三周。

Angelica Hill： 好吧，既然你刚刚上任，那你现在脑子里在想什么？你对什么感到兴奋？

Cherry Mui： 正如你所知，这对我来说是一个全新的角色，我还在学习，很多事情都需要我去学习……所以基本上就是学习。即使是这个角色的基本操作，我也需要学习，而且我一直在学习。但我也很兴奋，对这个新角色感觉很好。正如 Russ 提到的，我也非常喜欢他的说法。这是一个技术领导者的服务角色，所以我真的想找到一种方式，以我能做到的最好方式来服务团队和社区。正如你所知，核心团队以及社区中有很多非常有才华的工程师和贡献者……从来不缺乏想法。他们的想法源源不断。所以我很兴奋能与所有工程师和贡献者一起工作，我为他们的想法感到兴奋，讨论设计，并尝试将所有这些好的想法整合成一个连贯的整体。我想这就是我的职责所在。

现在我最关心的是，确保过渡过程尽可能顺利，并确保 Go 1.24 的发布会非常成功……这是最重要的事情。我想从长远来看，正如我们都知道的，Go 不仅仅是一种语言或编译器工具，它是一个完整的平台。所以我非常希望看到 Go 与平台的其他部分有更多的整合，比如工具、安全性，甚至是 AI，看看这些部分如何改变及演变。

Angelica Hill： 我必须说，虽然你才上任两周，但我很喜欢你的愿景，我也很期待看到它在两周后的进展。如果你在两周内就有这样的愿景和展望，我们几个月后再来看看。我已经准备好了。而且最后但绝非不重要的是，Russ，你说你会在旁边支持这个过渡……但你也有一个新角色，我想听听你对它的看法。所以我想了解你接下来的工作内容。我也会问你同样的问题---你对什么感到兴奋？你在 Go 领域的下一个篇章里最关心的是什么？

Russ Cox： 当然，当然。我们一直在思考如何应对 AI 的发展，特别是最近的大型语言模型（LLMs）带来了哪些新能力。我认为有一点非常有帮助---现在有很多关于 LLMs 的不切实际的乐观预期，人们认为它们将能够做一些非常了不起的事情。也许它们能做到，也许不能。但目前，我认为它们的主要优势是---我记得几年前看过一篇文章，把 LLMs 定义为一种“单词计算器”。计算机是一种数字计算器，而 LLMs 则是一种单词计算器。

所以当你需要处理大量文本时，拥有一个单词计算器听起来是个好主意。其中一个场景就是在软件维护时与他人合作，因为他们说的是英语，所以拥有一个能够处理英语文本的单词计算器似乎是个不错的选择。

我们现在正在研究如何帮助开源开发者管理他们自己的开源项目，并以 Go 作为试验平台。目标是尽量自动化那些没人真正愿意做的事情，比如基本的问题筛选，或者找出重复的问题。

目前我们有一个机器人，当你在 Go 仓库中提交新问题时，它会使用 LLMs 和向量数据库查找与此问题非常相关的其他问题，并列出最多六七个，可能有时是十个，我不记得具体的上限，但有一个相关性分数的阈值。所以有时它不会显示任何结果，有时它会说：“嘿，这些问题看起来与你的这个问题很相关。” 最初我们希望通过这个功能自动检测重复问题并关闭重复问题，但实际上很难区分“这是这个问题的重复”还是“是的，这看起来一模一样，但你以为已经修复了，现在又出现了，也许不同了。” 你无法通过报告区分这些情况。

但即使只是指出“嘿，看看这些其他问题可能有关联”，也非常有帮助。因为当你看到一个新问题时，你可能不知道其他人处理过的类似问题。你会发现：“哦，那个确实看起来一模一样。” 事实上，那个问题的修复中有一个细微的错误，可能导致了这个新问题。看到这些关联非常有帮助。特别是当项目变大时，我们已经无法把 Go 的所有细节都记在脑子里了，拥有这样的自动化检索功能简直太有用了。

所以我们在研究如何利用 LLMs 和最近的 AI 进展，来帮助处理这些人们不擅长、也不喜欢做的事情。翻阅所有问题来找出相关问题并不是我想花时间做的事情。而写代码是有趣的部分，我们不想让 AI 来代替，因为那是我们想做的事情。所以我们的基本想法就是：“让 AI 处理那些我们不想做的事。” 同时，我们也可以学到 AI 能做什么。对我来说，这还是一个实验，看看 LLMs 实际上能做些什么，因为我们谁也不真正知道。

Angelica Hill： 这太棒了！听起来你们正处于 Austin 领导下的“有趣模式”。我很喜欢听到这些。[笑声] 那么现在，我想从你们每个人那里听听---我们已经聊了很多关于你们的新职位、过去的经历以及让你们兴奋的事情……但我很好奇，关于 Go，或者 Go 的某个方面，有没有什么你们一直迫切想要解决或改进的问题，而现在你们也许有机会去推动它实现？我们可以从 Austin 开始。

Austin Clements： 好的，我会给出两个答案。首先，当我即将结束之前作为 Go 核心技术负责人角色时，我一直在尝试解决的一个问题是垃圾回收。垃圾回收需要消耗大量资源。很久以前，我做过一个微观架构分析，结果显示---垃圾回收的性能在某个低点，而理论上的垃圾回收性能上限远在天边。我们不可能让垃圾回收变得那么快，但我们应该能够缩小这个差距，而不仅仅是停留在现状。很多年前我做了这个分析，而每隔一段时间，我仍然会拿出当时做的那些幻灯片，提醒大家“我们仍然有这么大的差距。”

所以我一直在试验一种新的垃圾回收算法……作为技术负责人，你会借鉴团队里很多人的想法。我找到了一种方式把这些想法结合起来，以一种之前没有想到的方式进行整合。我把这个新的垃圾回收算法称为“Green Tea”（绿茶），因为当时我在日本的时候，几乎每天都去咖啡馆喝抹茶，并在那时取得了很大进展。所以，所有这些都联系在一起了。

我仍然在做很多实验，现在还不完全确定这个新算法是否会成功，但无论如何，这是一件非常有趣的事情。与我们当前的垃圾回收算法非常不同，虽然从用户的角度来看，它的功能还是一样的，但从技术层面来说，它非常有趣。

如果说没有别的收获，至少我们最近一直在思考如何将 SIMD（单指令多数据）引入 Go。我们已经思考了好几年，甚至内部已经有一些提案草案，但一直没有太大进展。我认为其中一个原因是，Go 核心团队中没有人真正有过多的 SIMD 编程经验。我们没有太多关于 SIMD 编程的内部专业知识。

而这个新垃圾回收算法的一个特点是，它围绕一系列非常紧凑的计算核心构建，这与当前的垃圾回收算法不同。这也意味着我们可以深入优化其中的一些核心，特别是使用 SIMD。因此，这为我提供了一个很好的机会，真正学习并积累 SIMD 编程的经验。我原本设想的那些“我们可以暴露出漂亮的 API 让 SIMD 更加优雅”的想法，在真正实践后发现完全行不通，因为实际操作起来完全是一团糟。

这是我在过去近 10 年里一直想解决的问题，现在我正试图在卸任 Go 核心技术负责人之前做一些尝试。当我转到 Go 总体团队的技术负责人后，我迫切想要解决的一个问题与我之前提到的编程乐趣有关。几年前，Russ 发起了所谓的 Go 2 进程，虽然我们知道它仍然是 Go 1。但是，Go 2 进程的关键部分是 Russ 让大家提交关于生产系统中引起摩擦的经验报告。我认为这个过程非常成功。

我们收集到了生产环境中最痛苦的一些问题，并且在过去几年中一直在逐步解决这些问题。我们还没有完全解决所有问题，但进展很好。不过，我认为这个过程中遗漏了一些“小问题”。显然，这些大问题非常重要，但工程师们每天都在写代码，而有时一些小问题会让人觉得：“为什么 Go 要让我这么做？这真是太傻了。” 正如我一开始所说的，我不想进来就把 Go 的基础推翻重建。我非常重视 Go 的稳定性，但我也相信我们可以从小的方面入手，做一些改进，让 Go 更有趣、更高效。

Angelica Hill： 听起来你已经列出了行动计划，我非常期待看到这些变化。我完全同意你提出的第二个观点，关注那些小细节，尽管它们看似微不足道，但对于每天编写代码的工程师来说，影响非常大。Cherry，我想听听你一直以来思考的是什么问题；你现在也许有了更多的领导力或时间去解决它，所以你可能会投入更多的精力去思考和解决这些问题。

Cherry Mui： 就像 Austin 一样，我也非常重视稳定性，所以我不打算改变一切并从头开始重建。但部分与 Austin 提到的相关，Go 是关于大规模编程的，所以无论是扩展到更多的人，还是扩展到更多的机器都很重要。随着 Go 的用户群体迅速增长，需求也越来越多，而 Go 团队的资源非常有限。核心团队的人数几乎没有增长，甚至有时会减少。因此，构建一个能够更好适应更多人和需求的平台非常重要。我们需要构建工具、API 或平台，能够让其他人基于这些去构建自己的解决方案。这是非常重要的。

我还希望解决扩展到机器的问题。Go 在扩展机器方面做得很好，它内置了非常好的并发支持。但随着硬件的发展，越来越多的核心、更大的机器，以及更多的容器和服务，问题也开始出现。我们看到越来越多的扩展问题，尤其是在处理大量核心或大内存等方面。我希望有机会解决这些问题。

Angelica Hill： 你指出的这些问题都非常重要，期待看到你在这份新工作中逐渐深入探讨这些问题。我相信你将与社区进行更多对话，解决这些对全球 Gophers 都非常重要的问题。

我还想问你们一个最后的问题，关于 Go 的社区。我们都是工程师，代码当然很重要，但让我加入 Go 社区的一个重要原因是人。抛开语言本身不谈，抛开它能做的奇妙事情不谈，社区中的人让这个社区变得特别。无论是他们的才华、想法，还是他们在网上就决策展开的热烈讨论，我都非常欣赏。所以我想听听 Austin，你对如何与这个充满激情的社区互动有什么想法？

Austin Clements： 这很难，因为社区非常庞大。我认为 Go 项目在过去几年中做了很多很棒的事情，来培养和维持一个强大的社区。我认为我们有很好的社区标准，这非常重要；我们也重视多样化的社区形式，这也很重要。就像技术问题需要多样化的观点一样，社区也需要多样化的视角。

我一直在思考的一个问题是，如何减少 Google 内部 Go 团队与外部社区之间的障碍。坦率地说，我在网上的活跃度远不如 Russ。在过去的 12 年里，Go 团队与外界的很多沟通都是通过 Russ 进行的。我希望拓宽这个渠道，让更多人参与进来。我认为这不仅有助于让 Google 内部其他优秀的工程师被更多人看到，也能帮助打破我们团队与社区之间的障碍。

我还不确定很多事情的具体形式。一个小想法是，Russ 有一个非常受欢迎的个人博客，他会在上面发布一些关于 Go 的详细内部思考，尤其是一些尚未正式确认的想法。但我认为这些想法发布在 Russ 的个人博客上有点可惜。

所以我在考虑如何将这种模式扩展到团队的其他成员，甚至可能包括社区成员。我认为团队内部有很多有趣的思考，但目前很多都没有传递给外部。我觉得部分原因是我们没有一个合适的平台来做这件事。我希望能够创建一个平台，任何团队成员都可以分享他们的想法，即使这些想法还不成熟，方向还不明确，但我们可以让这些讨论过程公开，而不仅仅是最终产品。

Angelica Hill： 我觉得这是一个非常棒的想法。我个人也非常期待这个变化。请纠正我，如果我理解错了，但我听到的感觉是……当我刚加入 Go 社区时，我记得在我第一次 Go 见面会的一个小时内，有人问我：“你认识 Russ 吗？你认识 Rob 吗？” 当时有三四个名字，如果你不认识这些人，似乎你就不算是真正的 Gopher。这些人几乎成了 Go 的“代言人”。我当时看到周围有这么多有趣、多样化的人，而 Russ 当然也非常有趣，但你能明白我的意思吗？这种“Go 的明星人物”的感觉一直存在。而这给人一种无形的等级感。

我知道 Russ 你绝不会这么说，也没有人有意去建立这样的层级，但我确实感受到了这种现象，而且我相信这也是很多人感受到的。这种感觉让人觉得 Go 社区有一种无形的门槛，只有那些特别外向的人能突破。我觉得我之所以认识 Russ，是因为我主动打招呼：“你好，我是 Angelica，你好吗？” 但不是每个人都愿意这么做。

坦白说，当时我对 Go 语言还没有太多认识，所以并不知道 Russ Cox 的“伟大之处”。如果是几年后，我可能会紧张得不敢这样做。所以你能理解我的意思吗？这是你们也注意到的问题吗？你们是否在尝试改变这种无意间形成的 Gopher 等级制度？

Russ Cox： 是的，绝对如此。这确实是个棘手的问题。我们也完全意识到这种现象，虽然这并不是有意为之，但它确实是 Go 项目结构中一个容易出现但不幸的结果。我们确实想打破这种现象。然而，我认为保持领导层的存在对于维持 Go 语言的一致性也很重要。所以如何平衡这两者是一个挑战。

Angelica Hill： 好的，Cherry，我可没忘记你。我想听听你的想法，特别是你打算如何与 Go 社区互动。我知道你负责的领域是许多 Gopher 非常关心的部分，他们对此投入了很多精力。我想了解一下你是如何从社区中汲取力量的。

Cherry Mui： 是的。正如 Austin 提到的，这确实是一个棘手且难以解决的问题。但是我也认为，倾听社区和 Go 用户的反馈非常重要。这实际上是 Go 最重要的部分。这也带来了许多我们核心团队成员可能很难想到的点子和机会。我们是一群编译器和运行时的工程师，基于不同的原因，我们的思考方式可能与大多数 Go 用户不同。用户希望用 Go 编写的代码与我为编译器编写的代码大不相同。因此，我真的认为我们应该更多地倾听他们的声音，了解他们真正想用 Go 做什么，他们面临哪些问题，以及我们可以做些什么来解决这些问题。

至于具体的形式，我目前还不确定，也许我们会做更多的用户研究或 QA（问题与解答）环节。我不知道具体形式会是什么，但我真的很想更多地听取来自社区和用户的反馈。

Angelica Hill： 为了澄清一下，针对那些可能在听这期节目但不太了解 Go 团队、Google 和 Go 社区互动方式的人，实际上已经有许多现有的论坛。比如每年都会发布 Go 开发者调查问卷，还有许多围绕 Go 语言的公开讨论论坛……

我只是在想，Austin，你提到的一个挑战是，随着社区的扩大，那些非常投入并且熟悉这些讨论去向的人知道该去哪，比如 Russ 的博客，或者某些问题跟踪器。但对于新加入的 Gopher，他们可能不太确定该如何正确地参与。再加上如此庞大的用户群，我自己有时也会参与一些问题讨论，看着 200 条往返的消息，然后想，“嗯，我真的想加入这个讨论吗？还是算了吧，我先旁观一下。”

Russ Cox： 我也经常有这种感觉。

Angelica Hill： 其实，我们可以用这个话题来结束我们的讨论。对于那些资深的 Gopher、新入门的 Gopher，或者想重新参与 Go 社区的人，他们应该如何保持关注，尤其是在即将到来的变化中跟进你们的工作？Russ，你能列举一些方法吗？然后 Cherry 和 Austin，如果 Russ 漏掉了什么，你们可以补充。

Russ Cox： 当然。这取决于你想获取多少信息。Golang Nuts 邮件组的讨论量非常大。Golang dev 邮件组的流量相对较小，但当有技术开发问题时，通常会在那里讨论。

你可以访问我们的代码审查服务器，网址是 go-review.googlesource.com。如果你愿意，你可以跟踪每一次变更，那里相当于所有的 pull request（拉取请求）。你也可以去 GitHub 上的 issue tracker（问题跟踪器），它也可以通过 go.dev/issue 访问。

另一个稍微低流量的地方是提案问题。这可以通过 go.dev/s/proposal-minutes 访问，也可以直接在 Go 的问题跟踪器上查找 Issue 33502。我们每周发布一次，列出哪些提案问题有活跃讨论。

如果你想跟进提案，并确保你的意见得到表达，你可以标星这个问题，然后每周都会收到 GitHub 邮件，里面列出当前活跃的提案。你可以每周浏览一下，确保你想表达的观点已经被提出来了，或者你可以自己提出。这是一种低流量但高影响力的参与方式。

这些是我能想到的几种方式。当然，参加会议、与人交流、参加见面会也是非常好的方式。但这是我能想到的一些直接的电子方式。

Angelica Hill： 我会在节目备注中添加提到的链接。如果你在听这期节目，我会把刚才提到的资源链接放在里面。另外，我还会放上 Go Bridge 的链接。你可以通过链接访问 YouTube 和 meetup 页面，查看全球 Go 见面会的列表。当然，如果你想继续参与，可以继续收听 Go Time，或者参加我们全球的许多会议。我也毫不羞愧地为 GopherCon 做个广告，这是一个非常棒的会议，组织者们做了出色的工作，结构非常合理……[笑声]

非常感谢你们花时间与我共度这一个小时。能够了解你们的想法、听到你们对新职位的期待，真是太棒了。我相信我代表整个 Go 社区和 Go Time 的听众说，我们非常期待，也会全力支持你们，更多精彩在未来！

Angelica Hill： 现在我们要进入节目中更“劲爆”的部分，Russ 知道我最喜欢的环节，就是讨论那些不太受欢迎的观点。

Angelica Hill： 那么，谁有不太受欢迎的“劲爆”观点呢？

Russ Cox： 我有一个，可能在这个房间外不太受欢迎……那就是，美国最适合软件工程师工作的地方是波士顿地区。我看了看，Cherry、Austin 和我都在波士顿，所以显然这是对的。

Angelica Hill： 等等，真的吗？

Austin Clements： 是的。

Angelica Hill： 为什么？我觉得你需要证明这个说法。

Russ Cox： 这就是客观事实。

Austin Clements： 数据统计。

Angelica Hill： 所以我们要抛弃“国王模式”，但你说波士顿是最好的地方只是因为“我们在这里”。[笑声]

Russ Cox： 完全正确。我们没有地震，马萨诸塞州不会沉入海底。

Angelica Hill： 嗯，我会考虑这个观点。我可能不会完全同意，但我会接受它。Cherry，Austin？

Cherry Mui： 好吧，我来说。我通常没有太多不受欢迎的观点，可能更像是不受欢迎的偏好。我不是那种特别有主见的人，但是我确实有一个。你刚才提到了 pull request（拉取请求）……我觉得 GitHub 的 pull request 工作流程非常难理解。对我来说真的很难。我觉得 Gerrit 的CL模型要好得多，操作起来更简单。

Austin Clements： 同意！

Angelica Hill： 你能再详细解释一下吗？是步骤的顺序问题吗？具体是什么让你感到困扰？

Cherry Mui： 是的。假设我只是想给某个我从未参与过的项目提交一个一行的补丁……我首先得把这个项目 fork 到我的 GitHub 页面上，创建一个分支，然后提交到我的分支，最后再发起一个 pull request……在那种情况下，我宁愿发一封邮件，说“这是一个一行的变更，我想做这个变更。”

Angelica Hill： [笑声]

Cherry Mui： 为什么要这么麻烦呢……我觉得真的很难。

Angelica Hill： 好的，GitHub 的小伙伴们，快点解决这个问题吧。Austin？

Austin Clements： 嗯，让我看看我能多快把自己“取消”。技术债务其实是好事，前提是它被当作一种投资来有意管理。我认为我们的行业对技术债务有一种非常本能的反应，但我喜欢把技术债务看作是一种债务。就像金融投资一样，有些技术债务的利率非常低，这可能是一个好投资，因为它意味着你可以把工程资源转移到更有价值的工作上。事实上，修复这部分技术债务的成本可能比继续“支付利息”更高，因为你很可能会引入新的 bug。

当然，利率高的技术债务是个问题。它经常导致 bug，或者影响你的开发速度，甚至影响团队成员的幸福感。但正因为我相信技术债务可以是好事，我也认为重要的是要营造一种文化，让人们真正有权力在技术债务成为问题时还清它。这很棘手，因为通常技术债务从低利率变为高利率的时刻，正是你想构建新功能、推出新产品的时候。但我认为必须有一种文化，允许你在需要修复时去修复，而在不需要时可以放手不管。

Angelica Hill： 当你开始说这个观点时，我心想“哦，我不确定……” 但听你解释之后，我觉得可能这个观点并不会那么不受欢迎。

非常感谢你们的时间。我的不受欢迎的观点是：我们需要一个喝抹茶的 Gopher，它是浅绿色的，可能还有一些漂亮的绿色樱花发型，还有一只脚踩在王冠上，象征着新时代的到来。[笑声] 这次聊天真是太愉快了。我希望很快能再次邀请你们。祝你们度过愉快的每一天、每一周、每一个月、每一年，继续推动 Go 语言的美丽发展。

Russ Cox： 非常感谢。这真是太有趣了。

Cherry Mui： 谢谢。

Austin Clements： 非常感谢。

原文链接: https://dashen.tech/2018/08/06/RSC的交棒/

版权声明: 转载请注明出处.

清澄秋爽

苹果树下的思索者书写是对思维的缓存

RSC的交棒

文章目录