Go 博客

Go、开源、社区

Russ Cox
2015年7月8日

欢迎

[这是我在 2015 年 Gophercon 大会上的开场主题演讲稿。 视频在这里。]

感谢大家远赴丹佛来到这里，也感谢所有观看视频的朋友们。如果这是你第一次参加 Gophercon，欢迎！如果你去年来过，欢迎回来！感谢组织者们为举办这样的会议所付出的辛勤工作。我很高兴来到这里，能够与大家交流。

我是 Go 项目的技术负责人，也是 Google 的 Go 团队成员。我和 Rob Pike 共享这个角色。在这个角色中，我花费大量时间思考 Go 开源项目的整体情况，特别是它的运行方式、开源的意义以及 Google 内部和外部贡献者之间的互动。今天我想与大家分享我对 Go 项目整体的看法，然后在此基础上解释我对 Go 开源项目发展方向的看法。

为什么选择 Go？

首先，我们需要回到起点。我们为什么要开始开发 Go？

Go 旨在提高程序员的生产力。我们希望改进 Google 的软件开发流程，但 Google 面临的问题并非 Google 独有。

有两个总体目标。

第一个目标是创造一种更好的语言，以应对可扩展并发性的挑战。所谓可扩展并发性，指的是能够同时处理许多事务的软件，例如通过来回发送网络流量来协调一千台后端服务器。

如今，这种软件有一个更短的名字：我们称之为云软件。可以公平地说，Go 在云计算运行软件之前就被设计用于云计算。

更大的目标是创造一个更好的环境，以应对可扩展软件开发的挑战，这种软件由许多人开发和使用，他们之间的协调有限，并且需要维护数年。在 Google，我们有数千名工程师编写和共享他们的代码，试图完成他们的工作，尽可能地重用其他人的工作，并在拥有超过十年历史的代码库中工作。工程师经常在工作或至少查看最初由其他人编写的代码，或者他们几年前编写的代码，这通常等同于一回事。

Google 内部这种情况与 GitHub 等网站上实践的大规模现代开源开发有很多共同之处。正因如此，Go 非常适合开源项目，帮助它们在很长一段时间内接受和管理来自大型社区的贡献。

我相信 Go 的成功很大程度上是因为 Go 非常适合云软件，Go 非常适合开源项目，而且这两个领域都恰好正在软件行业中越来越受欢迎和重要。

其他人也做了类似的观察。以下列举两个例子。去年，在 RedMonk.com 上，Donnie Berkholz 撰写了一篇关于“Go 作为云基础设施的新兴语言”的文章，指出“[Go 的]主要项目……以云为中心，或者是为了处理分布式系统或瞬态环境而设计的。”

今年，在 Texlution.com 上，作者撰写了一篇题为“为什么 Golang 注定会成功”的文章，指出这种对大型开发的关注可能甚至比对 Google 本身更适合开源：“这种开源适应性是我认为你即将看到越来越多的 Go 的原因……”

Go 的平衡

Go 是如何实现这些目标的？

它如何使可扩展并发性和可扩展软件开发变得更容易？

大多数人回答这个问题时会谈到通道和 goroutine，以及接口、快速构建、go 命令和良好的工具支持。这些都是答案的重要组成部分，但我认为它们背后有一个更广泛的概念。

我认为这个概念是 Go 的平衡。任何软件设计中都存在相互竞争的关注点，并且有一种非常自然的趋势试图解决所有你预见到的问题。在 Go 中，我们明确地尝试没有解决所有问题。相反，我们试图做到足够好，以便您可以轻松地构建自己的自定义解决方案。

我总结 Go 选择的平衡的方式如下：**少做。多启用。**

少做，但多启用。

Go 无法做到一切。我们不应该尝试。但是如果我们努力去做，Go 可能能够做好一些事情。如果我们仔细选择这些事情，我们就可以奠定一个基础，开发人员可以在该基础上轻松构建他们需要的解决方案和工具，并且理想情况下可以与其他人构建的解决方案和工具进行互操作。

示例

让我用一些例子来说明这一点。

首先，Go 语言本身的大小。我们努力减少概念的数量，以避免在大型开发者社区的不同部分形成相互难以理解的方言的问题。在 Go 中，任何想法只有在简化到其本质并具有明确的优势证明添加的复杂性后才会被纳入其中。

一般来说，如果我们希望 Go 做好 100 件事，我们不能进行 100 次单独的更改。相反，我们尝试研究和理解设计空间，然后确定一些协同工作的更改，并且这些更改可以实现其中大约 90 件事。我们愿意牺牲剩下的 10 件事，以避免使语言臃肿，以避免仅仅为了解决今天看起来很重要但在明天可能消失的特定用例而添加复杂性。

保持语言简洁可以实现更重要的目标。简洁使 Go 更易于学习、更易于理解、更易于实现、更易于重新实现、更易于调试、更易于调整和更易于演进。少做可以多启用。

我应该指出，这意味着我们拒绝了许多其他人的想法，但我向你保证，我们拒绝了更多我们自己的想法。

接下来是通道和 goroutine。我们应该如何构建和协调并发和并行计算？互斥锁和条件变量非常通用，但非常底层，因此很难正确使用。像 OpenMP 这样的并行执行框架则非常高层，只能用于解决范围狭窄的问题。通道和 goroutine 介于两者之间。它们本身并不能解决很多问题。但它们功能强大，可以轻松地进行排列以启用对并发软件中许多常见问题的解决方案。少做——真正做到足够好——可以多启用。

接下来是类型和接口。拥有静态类型可以实现有用的编译时检查，这是像 Python 或 Ruby 这样的动态类型语言所缺乏的。同时，Go 的静态类型避免了传统静态类型语言中的许多重复，使其感觉更轻量级，更像动态类型语言。这是人们最早注意到的东西之一，Go 的许多早期采用者都来自动态类型语言。

Go 的接口是其中的关键部分。特别是，省略 Java 或其他具有静态层次结构的语言中的“implements”声明使接口更轻量级且更灵活。没有这种严格的层次结构可以启用诸如测试接口之类的习惯用法，这些习惯用法描述现有的、不相关的生产实现。少做可以多启用。

接下来是测试和基准测试。大多数语言中是否缺乏测试和基准测试框架？它们之间是否存在一致性？

Go 的测试包并非旨在解决这些主题的每个方面。相反，它旨在提供大多数更高级工具所需的​​基本概念。包具有通过、失败或跳过的测试用例。包具有运行的基准测试，可以通过各种指标进行衡量。

在这里少做是为了尝试将这些概念简化为其本质，创建一个共享词汇表，以便更丰富的工具可以互操作。这种一致性支持更高级的测试软件，例如 Miki Tebeka 的 go2xunit 转换器，或 benchcmp 和 benchstat 基准测试分析工具。

因为确实存在关于基本概念表示的一致性，所以这些更高级的工具适用于所有 Go 包，而不仅仅是那些努力选择加入的包，并且它们可以彼此互操作，例如，使用 go2xunit 并不排除也使用 benchstat，如果这些工具是，比如说，竞争测试框架的插件，那么情况就会是这样。少做可以多启用。

接下来是重构和程序分析。因为 Go 用于大型代码库，所以我们知道它需要支持源代码的自动维护和更新。我们还知道，这个主题太大，无法直接构建在 Go 中。但我们知道我们必须做的一件事。在我们尝试在其他环境中进行自动化程序更改的经验中，我们遇到的最显著的障碍实际上是以开发人员可以接受的格式写出修改后的程序。

在其他语言中，不同团队使用不同的格式约定很常见。如果程序的编辑使用了错误的约定，它要么写入源文件的一部分，使其看起来与文件的其余部分完全不同，要么重新格式化整个文件，从而导致不必要且不需要的差异。

Go 语言没有这个问题。我们在设计 Go 语言时，就考虑到了 gofmt 的可能性，我们努力使 gofmt 的格式化结果对所有 Go 程序都适用，并且确保 gofmt 从最初的公开发布之日起就存在。Gofmt 实现了如此一致的格式，以至于自动化更改与文件中的其他部分融为一体。你无法分辨特定的更改是由人还是由计算机完成的。我们没有构建显式的重构支持。建立一个商定的格式化算法，就足以成为独立工具开发和互操作的共享基础。Gofmt 促成了 gofix、goimports、eg 等其他工具的诞生。我相信这方面的工作才刚刚开始，还有更多的事情可以做。

最后，构建和共享软件。在 Go 1 发布之前，我们构建了 goinstall，它演变成了我们现在熟知的“go get”。该工具定义了一种标准的零配置方式，用于在 github.com 等网站上解析导入路径，后来还通过发出 HTTP 请求的方式，解析其他网站上的路径。这种商定的解析算法促成了其他基于这些路径工作的工具的诞生，其中最值得注意的是 Gary Burd 创建的 godoc.org。如果你还没有用过它，你可以访问 godoc.org/the-import-path，其中 “the-import-path” 是任何有效的“go get”导入路径，网站会获取代码并显示其文档。一个很好的副作用是，godoc.org 充当了 Go 包公开可用的大致主列表。我们所做的仅仅是赋予导入路径明确的含义。少做，多得。

你会注意到，许多这些工具示例都是关于建立共享约定。有时人们会将 Go 称为“有主见”的，但背后有更深层的原因。同意共享约定的限制，是启用能够互操作的广泛工具类别的一种方式，因为它们都使用相同的底层语言。这是一种非常有效的方法，可以少做多得。具体来说，在许多情况下，我们可以做最少的工作来建立对特定概念的共享理解，例如远程导入或源文件的正确格式，从而启用能够协同工作的包和工具，因为它们都同意这些核心细节。

我稍后会回到这个想法。

为什么 Go 是开源的？

但在开始之前，正如我之前所说，我想解释一下我如何看待“少做多得”的平衡原则指导我们在更广泛的 Go 开源项目中的工作。为此，我需要从 Go 为什么是开源的开始讲起。

谷歌支付我的薪水以及其他人的薪水来开发 Go，因为如果谷歌的程序员生产力更高，谷歌就可以更快地构建产品，更轻松地维护它们，等等。但为什么开源 Go？为什么谷歌要与全世界分享这种好处？

当然，我们许多人在 Go 之前就参与过开源项目，我们自然希望 Go 也成为开源世界的一部分。但我们的偏好并非商业理由。商业理由是，Go 是开源的，因为这是 Go 成功的唯一途径。我们，在谷歌内部构建 Go 的团队，从一开始就知道这一点。我们知道，Go 必须尽可能多地提供给人们，才能获得成功。

封闭的语言会消亡。

一种语言需要庞大而广泛的社区。

一种语言需要很多人编写很多软件，这样当你需要一个特定的工具或库时，很有可能它已经被其他人编写过了，而且这个人比你更了解这个主题，并且花费了比你更多的时间来使其变得出色。

一种语言需要很多人报告错误，以便快速识别和修复问题。由于用户群规模大得多，Go 编译器比其松散基础的 Plan 9 C 编译器更加健壮和符合规范。

一种语言需要很多人将其用于各种不同的目的，以便语言不会过度适应一个用例，并在技术环境发生变化时变得毫无用处。

一种语言需要很多人想要学习它，这样人们就有市场编写书籍或教授课程，或举办像这样的会议。

如果 Go 停留在谷歌内部，这一切都不会发生。Go 会在谷歌内部窒息，或者在任何一家公司或封闭的环境中窒息。

从根本上说，Go 必须是开放的，并且 Go 需要你。如果没有你们所有人，如果没有全世界的人们将 Go 用于各种各样的项目，Go 就不可能成功。

反过来，谷歌的 Go 团队永远不可能大到足以支持整个 Go 社区。为了继续扩展，我们需要在少做的同时，启用所有这些“更多”。开源是其中很大一部分。

Go 的开源

开源意味着什么？最低要求是公开源代码，使其在开源许可证下可用，我们已经做到了。

但我们也开放了我们的开发流程：自从宣布 Go 以来，我们所有的开发工作都在公开进行，在对所有人开放的公开邮件列表上进行。我们接受并审查任何人的源代码贡献。无论你是否在谷歌工作，流程都是一样的。我们在公共场合维护我们的错误跟踪器，我们在公共场合讨论和制定变更提案，并在公共场合努力发布版本。公共源代码树是权威副本。更改首先发生在那里。它们只是稍后才被引入谷歌的内部源代码树。对于 Go 而言，开源意味着这是一项超越谷歌的集体努力，对所有人开放。

任何开源项目都是从几个人开始的，通常只有一个，但 Go 是三个：Robert Griesemer、Rob Pike 和 Ken Thompson。他们对他们希望 Go 成为的样子，他们认为 Go 在哪些方面比现有语言做得更好，都有一个愿景，Robert 明天早上会详细介绍这一点。我是加入团队的第二个人，然后是 Ian Taylor，然后，一个接一个，我们最终来到了今天，有数百位贡献者。

感谢迄今为止为 Go 项目贡献代码、想法或错误报告的许多人。我们试图在今天的程序中列出我们能找到的所有人。如果你的名字不在那里，我表示歉意，但还是要感谢你。

我相信迄今为止的数百位贡献者正朝着对 Go 的共享愿景努力。很难用语言表达这些事情，但我尽力解释了愿景的一部分：少做多得。

谷歌的作用

一个自然的问题是：与其他贡献者相比，谷歌的 Go 团队的角色是什么？我相信这个角色随着时间的推移而发生了变化，并且仍在继续变化。总体趋势是，随着时间的推移，谷歌的 Go 团队应该少做多得。

在 Go 公开之前，谷歌的 Go 团队显然是在独自工作。我们编写了所有内容的第一稿：规范、编译器、运行时、标准库。

然而，一旦 Go 开源，我们的角色就开始发生变化。我们需要做的最重要的事情是传达我们对 Go 的愿景。这很困难，我们仍在努力。最初的实现是传达这一愿景的重要方式，我们领导的导致 Go 1 的开发工作也是如此，以及我们发布的各种博客文章、文章和演讲。

但正如 Rob 在去年的 Gophercon 上所说，“语言已经完成了”。现在我们需要看看它如何运作，看看人们如何使用它，看看人们构建了什么。现在的重点是扩展 Go 可以帮助的工作类型。

谷歌的主要作用现在是支持社区，进行协调，确保更改能够很好地协同工作，并使 Go 忠于最初的愿景。

谷歌的主要作用是：少做多得。

我之前提到过，我们宁愿拥有少量功能来支持，比如说，90% 的目标用例，并避免为了达到 99% 或 100% 而需要增加数量级更多的功能。我们在我们熟悉的软件领域成功地应用了这种策略。但如果 Go 要在许多新的领域变得有用，我们需要这些领域的专家将他们的专业知识带到我们的讨论中，以便我们共同设计小的调整，从而为 Go 启用许多新的应用程序。

这种转变不仅适用于设计，也适用于开发。谷歌 Go 团队的角色继续从纯粹的开发转变为更多的指导。我肯定花更多的时间进行代码审查而不是编写代码，花更多的时间处理错误报告而不是自己提交错误报告。我们需要少做多得。

随着设计和开发转向更广泛的 Go 社区，我们 Go 的最初作者可以提供的最重要的事情之一是愿景的一致性，帮助保持 Go 的 Go 特性。我们必须达成的平衡当然是有主观性的。例如，可扩展语法的机制将是启用更多编写 Go 代码方式的一种方法，但这与我们希望拥有一个没有不同方言的一致语言的目标相违背。

我们有时不得不说不，可能比其他语言社区更多，但当我们这样做时，我们的目标是以建设性和尊重的态度这样做，将其视为澄清 Go 愿景的机会。

当然，这不仅仅是协调和愿景。谷歌仍在资助 Go 开发工作。Rick Hudson 今天晚些时候将讨论他在减少垃圾收集器延迟方面的工作，而 Hana Kim 将在明天讨论她将 Go 引入移动设备的工作。但我想明确一点，我们尽可能地将谷歌资助的开发与其他公司资助的开发或个人利用业余时间贡献的开发视为同等重要。我们这样做是因为我们不知道下一个好主意来自哪里。每个为 Go 做出贡献的人都应该有机会被听到。

示例

我想分享一些证据，证明随着时间的推移，谷歌的 Go 团队最初专注于协调而不是直接开发。

首先，Go 开发的资金来源正在扩大。在开源发布之前，显然谷歌支付了所有 Go 开发费用。在开源发布之后，许多个人开始贡献他们的时间，我们一直在缓慢但稳定地增加其他公司支持的贡献者数量，让他们至少兼职参与 Go 的开发，尤其是在使 Go 对这些公司更有用方面。今天，这个列表包括 Canonical、Dropbox、Intel、Oracle 等。当然，Gophercon 和其他地区性 Go 大会完全由谷歌以外的人组织，并且除了谷歌之外还有许多企业赞助商。

其次，Go 开发中由团队以外完成的概念深度正在扩展。

在开源发布后，最早的大型贡献之一是移植到 Microsoft Windows，由 Hector Chu 启动，由 Alex Brainman 和其他人完成。更多的贡献者将 Go 移植到其他操作系统。更多的贡献者重写了我们的大多数数值代码，使其更快或更精确，或两者兼而有之。这些都是重要的贡献，并且非常感谢，但它们大多不涉及新的设计。

最近，由Aram Hăvărneanu领导的一组贡献者将Go移植到了ARM 64架构上。这是Google以外的贡献者进行的第一个架构移植。这具有重要意义，因为通常，对新架构的支持比对新操作系统的支持需要更多的设计工作。架构之间的差异比操作系统之间的差异更大。

另一个例子是在过去几个版本中引入了对使用共享库构建Go程序的初步支持。此功能对于许多Linux发行版非常重要，但对于Google来说并不那么重要，因为我们部署的是静态二进制文件。我们一直在帮助指导整体策略，但大部分设计和几乎所有实现都是由Google以外的贡献者完成的，特别是Michael Hudson-Doyle。

我的最后一个例子是go命令对供应商管理（vendoring）的方法。我将供应商管理定义为将外部依赖项的源代码复制到您的代码树中，以确保它们不会消失或发生意外更改。

供应商管理并不是Google面临的问题，至少不像世界其他地方那样。我们将想要使用的开源库复制到我们的共享源代码树中，记录我们复制的版本，并且仅在需要时更新副本。我们有一条规则，即源代码树中只能存在特定库的一个版本，并且任何想要升级该库的人员都需要确保它仍然可以按Google代码预期的方式工作。所有这些都不会经常发生。这是供应商管理的懒惰方法。

相反，Google以外的大多数项目都采取更积极主动的方法，使用自动化工具导入和更新代码，并确保始终使用最新版本。

由于Google在供应商管理问题方面的经验相对较少，因此我们将其留给Google以外的用户来开发解决方案。在过去的五年中，人们构建了一系列工具。今天主要使用的工具有Keith Rarick的godep、Owen Ou的nut以及Dave Cheney的gb的gb-vendor插件。

当前情况存在两个问题。第一个是这些工具在开箱即用时与go命令的“go get”不兼容。第二个是这些工具彼此之间也不兼容。这两个问题都导致开发人员社区因工具而碎片化。

去年秋天，我们开始了一场公开的设计讨论，试图就这些工具的所有操作方式的一些基本内容达成共识，以便它们可以与“go get”和彼此协同工作。

我们的基本建议是，所有工具都同意在供应商管理期间重写导入路径的方法，以适应“go get”的模型，并且所有工具都同意一个文件格式来描述复制代码的源代码和版本，以便即使单个项目也可以一起使用不同的供应商管理工具。如果您今天使用一个工具，那么您明天仍然可以使用另一个工具。

以这种方式找到共同点非常符合“少做多得”的精神。如果我们能够就这些基本语义方面达成共识，那么这将使“go get”和所有这些工具能够互操作，并且它将能够在工具之间切换，就像关于如何在文本文件中存储Go程序的协议使Go编译器和所有文本编辑器能够互操作一样。因此，我们发布了我们关于共同点的提案。

发生了两件事。

首先，Daniel Theophanes在GitHub上启动了一个vendor-spec项目，提出了一个新提案，并接管了供应商管理元数据规范的协调和设计。

其次，社区几乎异口同声地说，在供应商管理期间重写导入路径是不可行的。如果代码可以在没有更改的情况下复制，则供应商管理会更加顺畅。

Keith Rarick提出了一个替代方案，建议对go命令进行最小的更改以支持供应商管理，而无需重写导入路径。Keith的提案无需配置，并且与go命令的其他方法非常契合。该提案将在Go 1.5中作为实验性功能发布，并且可能会在Go 1.6中默认启用。我相信各个供应商管理工具的作者已同意在Daniel的规范最终确定后采用它。

结果是，在下一个Gophercon上，我们应该能够在供应商管理工具和go命令之间实现广泛的互操作性，并且实现这一目标的设计完全是由原始Go团队以外的贡献者完成的。

不仅如此，Go团队关于如何做到这一点的提案基本上完全错误。Go社区非常清楚地告诉了我们这一点。我们接受了该建议，现在有一个供应商管理支持计划，我相信所有相关人员都对此感到满意。

这也是我们总体设计方法的一个很好的例子。在感觉到对经过充分理解的解决方案达成广泛共识之前，我们不会对Go进行任何更改。对于供应商管理，来自Go社区的反馈和设计对于达到这一点至关重要。

代码和设计都来自更广泛的Go社区的这种总体趋势对于Go非常重要。您，更广泛的Go社区，知道在您使用Go的环境中哪些有效，哪些无效。我们在Google不知道。我们将越来越多地依赖您的专业知识，并且我们将尽力帮助您开发设计和代码，以扩展Go使其在更多环境中变得有用，并与Go的最初愿景很好地契合。同时，我们将继续等待对经过充分理解的解决方案达成广泛共识。

这引出了我的最后一点。

行为准则

我曾论证过Go必须是开放的，并且Go需要您的帮助。

但实际上Go需要每个人的帮助。而并非每个人都在这里。

Go需要尽可能多的人的想法。

为了使这成为现实，Go社区需要尽可能地包容、友好、乐于助人并尊重他人。

Go社区现在已经足够大了，与其假设所有参与者都知道期望什么，我以及其他人认为，明确写下这些期望是有意义的。就像Go规范为所有Go编译器设定期望一样，我们可以编写一个规范来设定我们在线讨论和像这次这样的线下会议中的行为期望。

像任何好的规范一样，它必须足够通用以允许许多实现，但又必须足够具体以能够识别重要问题。当我们的行为不符合规范时，人们可以向我们指出这一点，我们可以解决问题。同时，重要的是要理解，这种规范不可能像语言规范那样精确。我们必须从假设我们所有人都会在应用它时保持理性的角度出发。

这种规范通常被称为行为准则。Gophercon有一个行为准则，我们都通过来到这里同意遵守它，但Go社区没有。我以及其他人认为Go社区需要一个行为准则。

但它应该说什么呢？

我相信我们可以做出的最重要的总体声明是，如果您想使用或讨论Go，那么您在这里受到欢迎，在我们的社区中。我相信这是我们渴望达到的标准。

即使没有其他原因（并且，需要明确的是，还有其他充分的理由），Go也需要尽可能大的社区。在行为限制社区规模的程度上，它会阻碍Go的发展。而行为很容易限制社区的规模。

技术界总体上以及Go社区尤其倾向于直率沟通的人。我不认为这是根本性的。我不认为这是必要的。但它在像电子邮件和IRC这样的在线讨论中尤其容易做到，在这些讨论中，纯文本没有得到我们在面对面互动中拥有的其他线索和信号的补充。

例如，我了解到，当时间紧迫时，我倾向于写更少的字，最终导致我的电子邮件看起来不仅匆忙，而且生硬、不耐烦，甚至轻蔑。这不是我的真实感受，但这就是我可能给人的印象，而这种印象足以让人们三思而后行是否要使用或为Go做出贡献。当一些Go贡献者给我发送私人邮件让我知道这一点时，我意识到了这一点。现在，当时间紧迫时，我会格外注意我写的内容，而且我经常会写比我自然会写的内容更多，以确保我传达了我的意图。

我相信，纠正我们日常互动中，有意或无意地驱赶潜在用户和贡献者的部分内容，是我们所有人为确保Go社区持续发展所能做的最重要的事情之一。一个良好的行为准则可以帮助我们做到这一点。

我们没有编写行为准则的经验，因此我们一直在阅读现有的准则，并且我们可能会采用现有的准则，也许会进行一些小的调整。我最喜欢的是Django行为准则，它起源于另一个名为SpeakUp！的项目。它被构建为对日常互动提醒列表的详细阐述。

“友善和耐心。热情欢迎。体谅他人。尊重他人。谨慎选择你的措辞。当我们意见不一致时，尝试理解为什么。”

我相信这体现了我们想要设定的基调、想要发送的信息以及想要为新贡献者创造的环境。我当然希望友善、耐心、热情欢迎、体谅他人并尊重他人。我不会每次都做到完美，如果我没有做到这一点，我欢迎您提出有益的建议。我相信我们大多数人都有同样的感受。

我没有提到基于或不成比例地影响种族、性别、残疾或其他个人特征的主动排斥，也没有提到骚扰。对我而言，从我刚才所说的可以推断出，排斥性行为或明确的骚扰在网上和线下都是绝对不可接受的。每个行为准则都明确地说明了这一点，并且我希望我们的准则也会这样做。但我相信SpeakUp！关于日常互动的提醒同样是一项重要的声明。我相信，为这些日常互动设定高标准会使极端行为更加清晰和容易处理。

我毫不怀疑Go社区可以成为科技行业中最友好、最热情、最体谅他人和最尊重他人的社区之一。我们可以做到这一点，这将使我们所有人受益并为我们增光添彩。

Andrew Gerrand一直领导着为Go社区采用适当行为准则的努力。如果您有任何建议、疑虑或行为准则方面的经验，或者想参与其中，请在会议期间找到Andrew或我。如果您周五还在，Andrew和我会在黑客日留出一些时间来讨论行为准则。

再说一次，我们不知道下一个好主意会从哪里来。我们需要所有可能的帮助。我们需要一个庞大而多元化的Go社区。

谢谢

我认为许多人通过“go get”发布软件供下载、通过博文分享见解或在邮件列表或 IRC 上帮助他人，都是这项广泛的开源工作的一部分，也是 Go 社区的一部分。今天在座的各位也都是这个社区的一员。

感谢接下来几天将抽出时间分享他们使用和扩展 Go 的经验的各位演讲者。

感谢各位观众抽出时间来到这里，提出问题，并让我们了解 Go 对你们的工作是否有帮助。当你们回到家后，请继续分享你们学到的知识。即使你们不每天使用 Go 工作，我们也希望看到 Go 的成功经验在其他领域得到应用，就像我们一直在寻找好的想法并将它们应用到 Go 中一样。

再次感谢大家付出努力来到这里，并成为 Go 社区的一员。

在接下来的几天里，请：告诉我们哪些方面做对了，哪些方面做错了，并帮助我们一起努力让 Go 变得更好。

请记住要友好、耐心、热情、体贴和尊重他人。

最重要的是，享受这次大会。