引言

连续第三年，Go团队和贡献者们在GopherCon前一天聚集在一起，讨论和规划Go项目的未来。会议包括了自行组织的分组讨论，上午进行了关于提案流程的城镇会风格讨论，下午则进行了基于贡献者选择的议题的分组圆桌讨论。我们邀请了五位贡献者撰写他们对今年峰会各种讨论的体验。

（摄影：Steve Francia。）

编译器与运行时（报告人：Lynn Boger）

Go贡献者峰会是一个与同样为Go做出贡献的其他人会面并讨论议题和想法的绝佳机会。

一天开始时，大家有时间互相认识。现场有Go核心团队成员和积极为Go做出贡献的其他人员的良好组合。之后，我们决定了大家感兴趣的议题，以及如何将大组分成小组。我感兴趣的领域是编译器，所以我加入了那个小组，并在大部分时间里都待在那里。

在我们的第一次会议上，列出了许多议题，因此编译器小组决定全天继续开会。我分享了一些我感兴趣的议题，许多其他人提出的议题也引起了我的兴趣。并非所有议题都得到了详细讨论；以下是我列出的最受关注和讨论最多的议题，以及对其他议题的一些简短评论。

二进制文件大小。人们对二进制文件大小表示担忧，特别是它随着每个版本都在增长。确定了一些可能的原因，例如内联函数和其它优化的增加。最有可能的是，有一部分用户需要小型二进制文件，另一部分用户则追求最佳性能，可能还有一部分用户对此不太在意。这引出了TinyGo的议题，并指出TinyGo并不是Go的完整实现，保持TinyGo不偏离Go并分裂用户群很重要。需要进行更多调查以了解用户需求以及导致当前大小的确切原因。如果有可能在不影响性能的情况下减小大小，那么可以进行更改，但如果影响了性能，一些用户将更倾向于更好的性能。

向量汇编。如何利用Go中的向量汇编已被讨论了一段时间，并且过去一直是大家感兴趣的话题。我将其分为三种可能性，因为它们都与向量指令的使用有关，但使用方式不同，从向量汇编的议题开始。这是编译器权衡的另一个例子。

对于大多数目标平台，标准包（如crypto、hash、math等）中都有关键函数，使用汇编是获得最佳性能的必要条件；然而，用汇编编写的大函数难以支持和维护，并且可能需要为每个目标平台提供不同的实现。一个解决方案是利用宏汇编或其他高级生成技术，使向量汇编更容易阅读和理解。

问题的另一个方面是，Go编译器是否可以通过增强Go编译器来转换代码序列以“向量化”代码，从而直接生成SIMD向量指令来编译Go源文件。在Go编译器中实现SIMD会增加复杂性和编译时间，并且不一定总是能产生性能更好的代码。代码转换的方式有时会取决于目标平台，这并非理想情况。

在Go中利用向量指令的另一种方式是提供一种方法，以便更容易地在Go源代码中使用向量指令。讨论的议题包括内建函数（intrinsics），或其它编译器（如Rust）中存在的实现。在gcc中，某些平台提供内联汇编，Go也可能提供此功能，但我从经验中知道，将内联汇编与Go代码混合会增加编译器在寄存器使用跟踪和调试方面的复杂性。它允许用户执行编译器可能不期望或不希望的操作，并增加了额外的复杂性。它可能被插入到不理想的位置。

总之，提供一种方法来利用可用的向量指令，并使其编写起来更轻松、更安全，这一点很重要。在可能的情况下，函数应尽可能使用Go代码，并可能寻找一种使用高级汇编的方法。有一些关于设计一个实验性向量包以尝试实现其中一些想法的讨论。

新的调用约定。几位与会者对提供基于寄存器的调用约定的ABI更改的议题感兴趣。报告了当前的状况和详细信息。讨论了在使用它之前还有哪些工作要做。首先需要编写ABI规范，而何时完成尚不清楚。我知道这将比某些目标平台更能使另一些平台受益，并且大多数其他平台的编译器都使用寄存器调用约定。

通用优化。讨论了对x86以外的一些平台更有益的某些优化。特别是，循环优化，如不变量提升和强度削弱，可以在某些平台上做得更好并带来更多好处。讨论了潜在的解决方案，而实现将很可能由那些认为这些改进重要性的平台来完成。

基于反馈的优化。对此进行了讨论和辩论，作为未来可能的增强功能。根据我的经验，很难找到有意义的程序来收集性能数据，这些数据稍后可用于优化代码。它会增加编译时间，并占用大量空间来保存数据，而这些数据可能只对一小部分程序有意义。

待提交的修改。小组中的几位成员提到了他们一直在进行并计划很快提交的更改，包括对makeslice的改进以及对rulegen的重写。

编译时间问题。简要讨论了编译时间。注意到在GOSSAFUNC输出中已添加了阶段计时。

编译器贡献者沟通。有人问是否需要一个Go编译器邮件列表。有人建议为此目的使用golang-dev，并在主题行中添加“compiler”以进行标识。如果golang-dev上的流量过大，那么稍后可以考虑一个编译器特定的邮件列表。

社区。我认为这一天在与社区中活跃并拥有相似兴趣领域的人建立联系方面非常有益。我能够认识许多我只知道在问题、邮件列表或CL中出现的用户名的朋友。我能够讨论一些议题和现有问题，并获得直接的互动反馈，而不是等待在线回复。我被鼓励就我看到的问题提出问题。这些联系不仅发生在这一天，还发生在整个会议期间，在第一天介绍后遇到其他人，这带来了许多有趣的讨论。希望这些联系将带来更有效的沟通，并改进将来对问题和代码更改的处理。

工具（报告人：Paul Jolly）

贡献者峰会期间的工具分组讨论进一步延长，在主会议期间组织了另外两个会话，由golang-tools小组负责。本摘要分为两部分：贡献者研讨会上的工具会话，以及主会议期间golang-tools会话的合并报告。

贡献者峰会。工具会话开始时，大约25名与会者进行了自我介绍，随后大家头脑风暴了议题，包括：gopls、ARM 32位、eval、signal、analysis、go/packages API、重构、pprof、模块体验、单体仓库分析、go mobile、依赖项、编辑器集成、编译器优化决策、调试、可视化、文档。许多人对许多工具感兴趣！

会话专注于两个领域（这是允许的所有时间）：gopls和可视化。Rebecca Stambler，gopls的主要作者，以及Go工具团队的其他成员，对大家使用gopls的体验感兴趣：稳定性、缺失的功能、编辑器中的集成工作情况等等？普遍的看法是，gopls状态非常好，并且对绝大多数用例都非常有效。集成测试覆盖率需要改进，但这对于所有编辑器来说都是一个很难“正确”处理的问题。我们讨论了更好的方法，让用户通过编辑器报告他们遇到的gopls错误、遥测/诊断、gopls性能指标，这些都是在主会议期间的golang-tools会话中得到更详细讨论的议题（见下文）。讨论的一个关键领域是如何扩展gopls，例如通过额外的go/analysis vet类检查、linter检查、重构等。目前还没有好的解决方案，但正在积极研究中。谈话转向了可视化这个非常广泛的话题，Anthony Starks（他恰好在GopherCon 2018上就Go用于信息显示做了精彩演讲）进行了演示介绍。

会议日。主会议期间的golang-tools会话是自该小组在GopherCon 2018成立以来一直在进行的月度电话会议的延续。完整的会议记录可在第一天和第二天的会话中获得。这些会话仍然吸引了大量与会者，每次都有25-30人参加。Go工具团队（这是该领域得到支持的一个好迹象）和Uber平台团队都派人参加了。与贡献者峰会不同，这些会话的目标是得出具体的行动项目。

Gopls。Gopls的“就绪度”是两个会话的重点。这个答案有效地归结为确定何时可以说“我们有一个不错的gopls初步版本”并告知编辑器集成商，然后编译一个已知与gopls一起工作的“认证”编辑器集成/插件列表。这个编辑器集成/插件的“认证”的核心是定义一个明确的流程，用户可以通过该流程报告他们在使用gopls时遇到的问题。性能和内存不是这个初始“发布”的障碍。关于如何扩展gopls的对话，在之前一天贡献者峰会上开始，现在仍在认真进行。尽管扩展gopls有很多明显的优点和吸引力（自定义go/analysis检查、linter支持、重构、代码生成…），但如何以可扩展的方式实现这一点还没有明确的答案。与会者一致认为，这不应被视为初始“发布”的障碍，而应继续进行。秉承gopls和编辑器集成的精神，Go工具团队的Heschi Kreinick提出了调试支持的议题。Delve已成为Go事实上的调试器，并且状态良好；现在需要建立调试器-编辑器集成的状态，遵循与gopls和“认证”集成类似的过程。

Go Discovery Site。第二次golang-tools会话以Go工具团队的Julie Qiu对Go Discovery Site的出色介绍以及快速演示开始。Julie谈到了Discovery Site的计划：开源该项目，用于搜索排名的信号，godoc.org最终将如何被取代，子模块应该如何工作，用户如何发现新的主版本。

Build Tags。随后讨论了gopls中的build tag支持。这是一个明显需要更好地理解的领域（用例目前正在issue 33389中收集）。鉴于这次讨论，JetBrains GoLand团队的Alexander Zolotov建议gopls和GoLand团队应该分享这方面的经验以及更多领域，因为GoLand已经获得了丰富的经验。

加入我们！关于工具相关的话题，我们还可以聊上好几天！好消息是，golang-tools的电话会议将在可预见的未来继续举行。我们非常鼓励任何对Go工具感兴趣的人加入：wiki有更多详情。

企业用途（报告人：Daniel Theophanes）

积极倾听较少发言的开发者的需求，将是Go语言面临的最大挑战，也是最大的成就。有很大一部分程序员不积极参与Go社区。其中一些是业务人员、营销人员或质量保证人员，他们也从事开发工作。有些会戴着管理帽，做出招聘或技术决策。有些人只是做好自己的工作，然后回家。最后，这些开发者很多时候在具有严格知识产权保护合同的公司工作。尽管其中许多开发者最终不会直接参与开源或Go社区的提案，但他们使用Go的能力取决于这两者。

Go社区和Go提案需要了解这些较少发言的开发者的需求。Go提案可能对哪些被采纳和使用产生重大影响。例如，vendor文件夹以及后来的Go模块代理对于严格控制源代码的公司来说非常重要，这些公司通常与Go社区的直接沟通较少。拥有这些机制使这些组织能够使用Go。因此，我们不仅要关注当前的Go用户，还要关注那些考虑过Go但最终未选择它的开发者和组织。我们需要了解其中的原因。

同样，如果Go社区关注“企业”环境，将可以吸引更多组织利用Go。通过确保Active Directory身份验证正常工作，那些被迫使用不同生态系统的用户可以将Go纳入考虑范围。通过确保WSDL正常工作，一部分用户可以将Go作为工具使用。没有人建议盲目地进行更改来迎合非Go用户。而是我们应该意识到Go语言和生态系统中未被发掘的潜力以及未被认识到的障碍。

虽然讨论了许多不同的外部征求意见的可能性，但这是一个我们根本上需要您帮助的问题。如果您所在的公司即使考虑过Go但最终没有使用它，请告诉我们原因。如果您所在的公司Go只用于一部分编程任务，而不是全部，为什么不用于更多任务？是否存在阻碍采用的特定障碍？

教育（报告人：Andy Walker）

今年贡献者峰会上我参与的圆桌会议之一是关于Go教育的，特别是我们为新Go程序员提供什么样的资源，以及如何改进它们。与会者中有许多充满激情的组织者、工程师和教育工作者，他们每个人都有自己独特的视角，无论是通过他们设计的工具、编写的文档还是为各种开发人员举办的研讨会。

早期，我们讨论了Go是否是一个好的第一门编程语言。我不确定，并表示反对。我认为Go不是一个好的第一门语言，因为它并非为此目的而设计。正如Rob Pike在2012年写道，“该语言是为编写—以及阅读、调试和维护—大型软件系统的开发者而设计的”。对我来说，这种指导理念很清晰：Go是为响应经验丰富的工程师在使用过程中感知到的缺陷而做出的深思熟虑的反应，而不是试图创造一种理想的编程语言，因此假设对编程概念有基本的熟悉度。

这在官方文档golang.org/doc中得到了体现。它直接介绍了如何安装语言，然后将用户引导到tour，该tour是为已经熟悉C语言风格的程序员设计的。之后，他们会转到How to Write Go Code，它提供了对经典非模块Go工作区的基本介绍，然后立即继续编写库和进行测试。最后，我们有Effective Go，以及一系列参考资料，包括spec，并附带一些示例。如果您已经熟悉C语言风格的语言，这些都是不错的资源，但仍然有很大的不足之处，对于完全的初学者，甚至是从Python等语言转过来的用户来说，几乎没有内容。

作为一个可访问的、交互式的起点，tour是使语言对初学者更友好的一个自然的首选目标，我认为仅靠它就能取得很大进展。首先，它应该是文档中的第一个链接，如果不是golang.org顶部栏的第一个链接，就应该置于最显眼的位置。我们应该鼓励好奇的用户立即开始尝试该语言。我们还应该考虑包含关于从其他常用语言过渡过来的可选介绍部分，以及他们在Go中可能遇到的差异，并提供交互式练习。这将极大地帮助新的Go程序员将他们已经熟悉的概念映射到Go。

对于有经验的程序员来说，应该对tour中的大部分部分提供可选的、更深入的讲解，让他们能够深入研究更详细的文档或交互式练习，列举Go中良好架构的设计原则。他们应该能找到这些问题的答案

• 为什么有这么多整数类型，而我大多数时候都被鼓励使用int？
• 有没有好的理由选择值接收器？
• 为什么有普通的int，但没有普通的float？
• 什么是发送/接收通道，以及我何时会使用它们？
• 我如何有效地组合并发原语，以及我何时不应使用通道？
• uint有什么用？我应该用它来限制用户使用正值吗？为什么不行？

当他们完成初次学习后，tour应该成为他们可以再次访问的地方，以更深入地研究一些更有趣的语言设计选择。

但我们可以做得更多。许多人学习编程是为了设计应用程序或解决特定问题，而他们最有可能想针对他们最熟悉的界面：浏览器。Go还没有一个好的前端故事。JavaScript仍然是唯一真正提供前端和后端环境的语言，但WASM正迅速成为一个重要的平台，我们可以有很多选择。我们可以在The Go Play Space中提供类似vecty的东西，或者针对WASM的Gio，让人们立即开始在浏览器中编程，激发他们的想象力，并为他们提供从我们的游乐场迁移到终端并最终迁移到GitHub的路径。

那么，Go是一个好的第一门语言吗？我真的不知道，但确实有相当多的人以Go作为起点进入编程行业，我非常想和他们交流，了解他们的旅程和过程，并听取他们的意见来塑造Go教育的未来。

学习平台（报告人：Ronna Steinberg）

我们讨论了Go的学习平台应该是什么样子，以及我们如何结合全球资源来有效地教授这门语言。我们普遍认为，可视化有助于教学和学习，而REPL（Read-Eval-Print Loop）非常有益。我们还概述了一些现有的Go可视化解决方案：模板、Go WASM、GopherJS以及SVG和GIF生成。

对于新手开发者来说，编译器错误难以理解的问题也被提了出来，我们考虑了一些如何处理它的想法，也许有一个错误库以及它们如何有用。一个想法是提供一个编译器包装器，用例子和解决方案来解释你的错误。

后来，一个新小组进行了第二轮会议，我们更加关注Go学习平台的UX应该是什么样的，以及我们是否以及如何将社区中现有的材料（演讲、博客文章、播客等）组织成一个人们可以从中学习的程序。这样的平台是否应该链接到那些外部资源？嵌入它们？引用它们？我们一致认为，类似门户的解决方案（链接到外部资源的门户）会使导航变得困难，并影响学习体验，这让我们得出结论，这种贡献不能是消极的，贡献者很可能需要选择加入才能将他们的材料放到平台上。然后，大家对增加一个投票机制到平台上的想法感到非常兴奋，有效地将学习者也变成了贡献者，并激励贡献者将他们的材料放到平台上。

（如果您有兴趣帮助Go的教育工作，请发送电子邮件至Carmen Andoh candoh@google.com。）

感谢！

感谢所有与会者在贡献者日进行了精彩的讨论，尤其感谢Lynn、Paul、Daniel、Andy和Ronna抽出时间撰写这些报告。