Go 官方博客

Go，开源，社区

Russ Cox
2015年7月8日

欢迎

[这是我在 Gophercon 2015 大会上的开幕主旨演讲内容。 视频请见此处。]

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

我是 Google Go 项目和 Go 团队的技术负责人。我和 Rob Pike 共同担任此职。在此职位上，我花费大量时间思考整个 Go 开源项目，特别是它的运行方式、开源的意义，以及 Google 内部和外部贡献者之间的互动。今天我想与大家分享我对 Go 项目整体的看法，并在此基础上解释我如何看待 Go 开源项目的发展演变。

为什么选择 Go？

首先，我们必须追溯到起点。我们为什么开始研发 Go？

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

有两个首要目标。

第一个目标是打造一种更好的语言来应对可伸缩并发的挑战。我所说的可伸缩并发是指能同时处理多项事务的软件，例如通过来回发送网络流量来协调一千台后端服务器。

如今，这类软件有了一个更简洁的名称：我们称之为云软件。可以公平地说，Go 是在云尚未运行软件之前为云设计的。

更大的目标是创建一个更好的环境，以应对可伸缩软件开发的挑战，即许多人共同开发和使用、彼此协调有限、并维护多年的软件。在 Google，我们有数千名工程师互相编写和分享代码，努力完成自己的工作，尽可能地重用他人的成果，并在一个拥有十多年历史的代码库中工作。工程师们经常处理或至少查看他人最初编写的代码，或者他们自己多年前编写的代码，这通常没什么区别。

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

我认为 Go 的大部分成功在于它非常适合云软件，非常适合开源项目，并且巧合的是，这两者在软件行业中越来越受欢迎和重要。

其他人也发表了类似的观察。这里有两个例子。去年，在 RedMonk.com 上，Donnie Berkholz 写了一篇关于“作为云基础设施的新兴语言的 Go”的文章，指出“[Go 的]主要项目……要么是以云为中心，要么是为处理分布式系统或临时环境而构建的。”

今年，在 Texlution.com 上，作者写了一篇题为“Go 注定会成功的原因”的文章，指出这种对大规模开发的关注可能比 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 的 testing 包并非旨在涵盖这些主题的方方面面。相反，它旨在提供大多数更高级工具所需的基本概念。包有通过、失败或跳过的测试用例。包有运行并可以通过各种指标衡量的基准测试。

在这里做得更少是尝试将这些概念提炼到本质，以创建共享词汇，从而使更丰富的工具能够互操作。这种一致性使得更高级的测试软件成为可能，例如 Miki Tebeka 的 go2xunit 转换器，或 benchcmp 和 benchstat 基准分析工具。

因为基本概念的表示形式确实存在一致性，这些更高级的工具适用于所有 Go 包，而不仅仅是那些努力选择加入的包，而且它们彼此互操作，例如使用 go2xunit 不会妨碍同时使用 benchstat，这与这些工具作为相互竞争的测试框架插件时的情况不同。少做，多赋能。

接下来是重构和程序分析。由于 Go 是用于大型代码库的，我们知道它需要支持源代码的自动维护和更新。我们也知道这个主题太大了，无法直接内置。但我们知道有一件事我们必须做。根据我们在其他环境下尝试自动化程序修改的经验，遇到的最主要的障碍实际上是以开发者可以接受的格式写出修改后的程序。

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

Go 没有这个问题。我们设计了语言以使 gofmt 成为可能，我们努力使 gofmt 的格式化对所有 Go 程序都可接受，并且我们确保从最初公开发布的第一天起 gofmt 就已存在。Gofmt 强制执行这种一致性，使得自动化修改可以融入文件的其余部分。你无法分辨某个特定的修改是人做的还是计算机做的。我们没有内置明确的重构支持。建立一个一致的格式化算法足以成为独立工具开发和互操作的共享基础。Gofmt 使得 gofix, goimports, eg 等工具成为可能。我相信这方面的工作才刚刚开始。还可以做得更多。

最后，构建和分享软件。在 Go 1 发布之前，我们构建了 goinstall，它演变成了我们今天熟知的“go get”。这个工具定义了一种标准的、零配置的方式来解析 github.com 等网站上的导入路径，后来又通过发出 HTTP 请求的方式来解析其他网站上的路径。这种一致的解析算法使得其他使用这些路径的工具成为可能，最显著的就是 Gary Burd 创建的 godoc.org。如果您还没有使用过它，对于任何有效的“go get”导入路径，您可以访问 godoc.org/the-import-path，该网站将抓取代码并显示其文档。一个不错的副作用是 godoc.org 成为了一个公开可用的 Go 包的粗略主列表。我们所做的只是赋予了导入路径一个清晰的含义。少做，多赋能。

您会注意到，许多这些工具示例都与建立共享约定有关。有时人们称 Go “固执己见”，但实际上有更深层的原因。同意共享约定的限制是使各种工具能够互操作的一种方式，因为它们都使用相同的基本语言。这是少做但多赋能的一种非常有效的方式。具体来说，在许多情况下，我们可以做最少的工作来建立对某个特定概念（如远程导入或源文件的正确格式化）的共享理解，从而促成能够协同工作的软件包和工具的创建，因为它们都认同这些核心细节。

我稍后会回到这个想法。

Go 为什么是开源的？

但首先，就像我之前说的，我想解释一下我认为“少做，多赋能”的平衡理念是如何指导我们在更广阔的 Go 开源项目上工作的。要做到这一点，我需要从 Go 为什么是开源的这个问题开始。

Google 支付我和其他人开发 Go，是因为如果 Google 的程序员更有效率，Google 就可以更快地构建产品，更容易地维护它们等等。但为什么要把 Go 开源呢？Google 为什么要与世界分享这份好处？

当然，在我们开发 Go 之前，我们中的许多人就参与过开源项目，我们自然希望 Go 成为开源世界的一部分。但我们的偏好并非商业理由。商业理由是 Go 之所以开源，是因为这是 Go 成功的唯一途径。我们，Google 内部构建 Go 的团队，从第一天起就知道这一点。我们知道 Go 必须向尽可能多的人开放才能成功。

封闭的语言会消亡。

一门语言需要庞大、广泛的社区。

一门语言需要很多人编写大量的软件，这样当您需要某个特定工具或库时，很有可能它已经被某个人编写出来了，这个人比您更了解这个主题，并且比您投入更多时间来使其变得出色。

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

一门语言需要很多人将其用于许多不同的目的，这样该语言就不会过度适应某个单一用例，从而在技术环境变化时变得无用。

一门语言需要很多人想学习它，这样才能形成一个市场，供人们撰写书籍、教授课程或举办像这样的大会。

如果 Go 留在 Google 内部，这一切都不可能发生。Go 会在 Google 内部，或者在任何一家公司或封闭环境中窒息而死。

从根本上说，Go 必须是开放的，Go 需要你们。没有你们所有人，没有全世界使用 Go 开发各种不同项目的人们，Go 就无法成功。

反过来，Google 的 Go 团队也永远不够大，无法支持整个 Go 社区。为了持续扩展，我们需要在少做的同时赋能所有这些“更多”。开源是其中的重要组成部分。

Go 的开源特性

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

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

任何开源项目都始于少数人，通常只有一人，但 Go 项目始于三人：Robert Griesemer、Rob Pike 和 Ken Thompson。他们对 Go 的未来以及 Go 如何超越现有语言有着明确的愿景，Robert 明天早上会更详细地谈论这一点。我是下一个加入团队的人，然后是 Ian Taylor，接着，我们一个接一个地发展到今天，拥有数百名贡献者。

感谢迄今为止为 Go 项目贡献代码、想法或错误报告的许多人。今天在大会手册的版面里，我们尽力列出了所有能列出的人。如果您的名字没有在其中，我深感抱歉，但仍然感谢您。

我相信迄今为止的数百名贡献者正在朝着 Go 可能实现的共同愿景努力。很难用言语来表达这些事情，但我尽力在前面解释了愿景的一部分：少做，多赋能。

Google 的角色

一个自然的问题是：与 Go 社区的其他贡献者相比，Google Go 团队扮演着什么角色？我认为这个角色随着时间推移一直在变化，并将继续变化。总体趋势是，随着时间的推移，Google 的 Go 团队应该少做并赋能更多。

在 Go 公开之前，在最初的那些日子里，Google 的 Go 团队显然是独自工作的。我们写下了所有东西的初稿：规范、编译器、运行时、标准库。

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

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

Google 目前的主要角色是赋能社区、进行协调、确保各项改动协同良好，并使 Go 保持其最初的愿景。

Google 的主要角色是：少做，多赋能。

我之前提到，我们宁愿拥有少量能够覆盖大约 90% 目标使用场景的功能，并避免为了达到 99% 或 100% 而需要数量级更多功能的情况。我们已经成功地将这一策略应用于我们熟悉的软件领域。但如果 Go 要在许多新的领域发挥作用，我们需要这些领域的专家将他们的专业知识带入我们的讨论中，以便我们能够共同设计出小的调整，从而为 Go 带来许多新的应用。

这种转变不仅适用于设计，也适用于开发。Google Go 团队的角色正在持续向引导方向转变，而纯粹的开发工作则有所减少。我肯定花更多时间进行代码评审，而非编写代码；花更多时间处理错误报告，而非自己提交错误报告。我们需要少做，多赋能。

随着设计和开发更多地转移到更广泛的 Go 社区，我们这些 Go 的原始作者能够提供的最重要的事情之一就是愿景的一致性，以帮助 Go 保持其本来的样子。我们必须达到的平衡无疑是主观的。例如，一种可扩展的语法机制可以提供更多编写 Go 代码的方式，但这将与我们拥有一个没有不同方言的统一语言的目标背道而驰。

我们有时不得不说“不”，或许比其他语言社区更多，但当我们这样做时，我们的目标是建设性和尊重地去做，并以此为机会阐明 Go 的愿景。

当然，并非全是协调和愿景。Google 仍然为 Go 的开发工作提供资金。Rick Hudson 今天晚些时候会谈论他关于减少垃圾收集器延迟的工作，Hana Kim 明天会谈论她关于将 Go 移植到移动设备上的工作。但我想明确指出，我们尽可能地将 Google 资助的开发视为与由其他公司资助或个人利用业余时间贡献的开发同等重要。我们这样做是因为我们不知道下一个伟大的想法会来自哪里。所有为 Go 做贡献的人都应该有机会被听到。

示例

我想分享一些证据来证明我的这一说法，即随着时间的推移，Google 的原始 Go 团队越来越注重协调而非直接开发。

首先，Go 开发的资金来源正在扩大。在开源发布之前，显然所有的 Go 开发都由 Google 资助。开源发布之后，许多个人开始贡献他们的时间，并且我们正在缓慢但稳步地增加由其他公司支持的贡献者数量，这些贡献者至少是兼职参与 Go 的工作，特别是那些与使 Go 对这些公司更有用相关的方面。今天，这份名单包括 Canonical、Dropbox、Intel、Oracle 等公司。当然，Gophercon 和其他地区性的 Go 大会完全由 Google 以外的人组织，并且它们除了 Google 之外还有许多企业赞助商。

其次，由原始团队外部进行的 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（依赖vendoring）的方式。我将 vendoring 定义为将外部依赖项的源代码复制到您的代码树中，以确保它们不会消失或在您不知情的情况下更改。

Vendoring 并不是 Google 面临的问题，至少不像世界其他地方那样面临。我们将我们想要使用的开源库复制到共享源代码树中，记录复制的版本，并且只有在需要时才更新副本。我们有一条规则，即源代码树中只能存在特定库的一个版本，任何想要升级该库的人的任务是确保它继续按依赖它的 Google 代码的预期运行。这些事情并不经常发生。这是一种懒惰的 vendoring 方法。

相比之下，Google 之外的大多数项目采用更积极的方法，使用自动化工具导入和更新代码，并确保他们始终使用最新版本。

由于 Google 在这个 vendoring 问题上经验相对较少，我们将其留给了 Google 外部的用户来开发解决方案。在过去的五年里，人们开发了一系列工具。目前主要使用的工具有 Keith Rarick 的 godep、Owen Ou 的 nut 以及 Dave Cheney 的 gb 的 gb-vendor 插件。

当前的情况存在两个问题。首先是这些工具与 go 命令的“go get”不兼容。其次是这些工具彼此之间也不兼容。这两个问题都导致开发者社区因工具而分裂。

去年秋天，我们发起了一场公开的设计讨论，试图就这些工具如何协同工作的一些基本原则达成共识，以便它们能够与“go get”以及彼此协同工作。

我们的基本提议是所有工具都同意在 vendoring 过程中重写导入路径，以适应“go get”的模型；并且所有工具都同意一种文件格式来描述复制代码的来源和版本，这样即使是同一个项目也可以同时使用不同的 vendoring 工具。如果您今天使用一种工具，明天仍然应该能够使用另一种工具。

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

发生了两件事。

首先，Daniel Theophanes 在 GitHub 上发起了一个名为 vendor-spec 的项目，提出了一个新的方案，并接管了 vendoring 元数据规范的协调和设计工作。

其次，社区基本上一致发声，表示在 vendoring 过程中重写导入路径是不可行的。如果代码可以在不更改的情况下被复制，vendoring 的工作会顺畅得多。

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

结果是，在下一届 Gophercon 上，我们应该能看到 vendoring 工具和 go 命令之间广泛的互操作性，而实现这一目标的方案完全是由原始 Go 团队之外的贡献者完成的。

不仅如此，Go 团队关于如何做这件事的提议基本上是完全错误的。Go 社区非常明确地告诉了我们这一点。我们采纳了他们的建议，现在有了一个 vendoring 支持方案，我相信所有参与其中的人都很满意。

这也是我们总体设计方法的一个很好的例子。在我们认为对一个充分理解的解决方案尚未达成广泛共识之前，我们不会对 Go 进行任何更改。对于 vendoring，来自 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 和我打算在 Hack Day 期间留出一些时间讨论行为准则。

重申一下，我们不知道下一个伟大的想法会从哪里来。我们需要一切能获得的帮助。我们需要一个庞大、多元化的 Go 社区。

谢谢

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

提前感谢接下来几天将花时间分享他们使用和扩展 Go 经验的演讲者们。

提前感谢所有在场的听众，感谢你们花时间来这里、提问题，并告诉我们 Go 对你们来说效果如何。回家后，请继续分享你们学到的东西。即使你们日常工作不使用 Go，我们也乐于看到 Go 中行之有效的方法被其他领域采纳，就像我们一直在寻找好想法带回 Go 中一样。

再次感谢大家努力来到这里并成为 Go 社区的一份子。

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

记住要友善、耐心、欢迎他人、体谅他人、尊重他人。

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