Russ Cox谈Go项目技术负责人的交接

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

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

过程中为符合中文惯用表达有适当删改, 版权归原作者所有.

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： 非常感谢。