Go 博客

2019 年贡献者峰会

Carmen Andoh 和贡献者
2019 年 8 月 15 日

介绍

Go 团队和贡献者连续第三年在 GopherCon 前一天举行峰会，讨论和规划 Go 项目的未来。活动包括自发组织分组讨论，上午围绕提案流程进行的市政厅式讨论，以及下午基于贡献者选择的主题进行的圆桌讨论。我们邀请了五位贡献者撰写文章，分享他们在今年峰会各种讨论中的体验。

（史蒂夫·弗朗西亚拍摄。）

编译器和运行时（Lynn Boger 的报告）

Go 贡献者峰会是一个绝佳的机会，可以与其他 Go 贡献者会面并讨论主题和想法。

当天首先是与会者见面。与会人员很好地融合了 Go 核心团队成员和其他积极贡献 Go 的人。随后，我们确定了感兴趣的主题以及如何将大组分成小组。我感兴趣的领域是编译器，因此我加入了该小组，并在大部分时间里都与他们在一起。

在我们的第一次会议上，提出了很多主题，因此编译器小组决定在当天继续开会。我分享了一些感兴趣的主题，其他人提出的许多主题也引起了我的兴趣。并非列表中的所有项目都进行了详细讨论；以下是引起最多兴趣和讨论的主题列表，以及对其他主题的一些简要评论。

**二进制文件大小**。有人对二进制文件大小表示担忧，尤其是它在每个版本中都在不断增长。确定了一些可能的原因，例如内联增加和其他优化。很可能有一组用户希望二进制文件小巧，另一组用户希望获得最佳性能，也许还有一些用户不在乎。这引发了 TinyGo 的话题，并指出 TinyGo 并非 Go 的完整实现，并且重要的是要防止 TinyGo 与 Go 分离并导致用户群分裂。需要进行更多调查以了解用户的需求以及导致当前大小的确切原因。如果可以在不影响性能的情况下减少大小，则可以进行这些更改，但如果性能受到影响，则一些用户会更喜欢更好的性能。

**向量汇编**。如何利用 Go 中的向量汇编讨论了一段时间，并且过去一直是人们关注的主题。我已将其分为三个单独的可能性，因为它们都与向量指令的使用有关，但它们的使用方式不同，首先是向量汇编主题。这也是编译器权衡的另一个例子。

对于大多数目标而言，标准包（如加密、哈希、数学等）中存在关键函数，其中必须使用汇编才能获得最佳性能；但是，使用汇编编写的函数过多会使它们难以支持和维护，并且可能需要针对每个目标平台进行不同的实现。一种解决方案是利用宏汇编或其他高级生成技术来使向量汇编更容易阅读和理解。

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

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

总之，提供一种利用可用向量指令的方法，并使其更易于编写和更安全非常重要。在可能的情况下，函数尽可能多地使用 Go 代码，并可能找到一种使用高级汇编的方法。有人讨论设计一个实验性的向量包以尝试实现其中一些想法。

**新的调用约定**。有几个人对提供基于寄存器的调用约定的 ABI 更改主题感兴趣。报告了当前状态以及详细信息。讨论了在可以使用它之前需要完成哪些工作。首先需要编写 ABI 规范，目前尚不清楚何时完成。我知道这将使某些目标平台比其他平台受益更多，并且大多数编译器在其他平台上都使用寄存器调用约定。

**通用优化**。讨论了除 x86 之外的某些平台更有益的某些优化。特别是，循环优化（例如不变量提升和强度削弱）可以完成并为某些平台提供更多收益。讨论了潜在的解决方案，实现可能取决于发现这些改进很重要的目标。

**反馈导向优化**。这被讨论并争论为一种可能的未来增强功能。根据我的经验，很难找到有意义的程序来用于收集性能数据，这些数据稍后可用于优化代码。它会增加编译时间，并且需要占用大量空间来保存数据，而这些数据可能仅对一小部分程序有意义。

**待提交的更改**。小组中的一些成员提到了他们一直在努力的更改，并计划很快提交，包括对 makeslice 的改进和 rulegen 的重写。

**编译时间问题**。简要讨论了编译时间。有人指出，阶段计时已添加到 GOSSAFUNC 输出中。

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

**社区**。我发现这一天在与社区中活跃且具有类似兴趣领域的人们建立联系方面非常有益。我能够结识许多人，我之前只知道他们在问题或邮件列表或 CL 中出现的用户名。我能够讨论一些主题和现有问题，并获得直接的交互式反馈，而不是等待在线回复。我被鼓励针对我遇到的问题编写问题。这些联系不仅发生在这一天，而且在整个会议期间遇到其他人时也发生过，因为在第一天就进行了介绍，这导致了许多有趣的讨论。希望这些联系将导致更有效的沟通以及未来问题和代码更改的改进处理。

工具（Paul Jolly 的报告）

贡献者峰会期间的工具分组讨论采取了扩展形式，golang-tools 小组在主要会议日期组织了另外两场讨论。本摘要分为两部分：贡献者研讨会上的工具讨论，以及主要会议日期 golang-tools 讨论的综合报告。

**贡献者峰会**。工具讨论从大约 25 人的介绍开始，随后进行了头脑风暴，主题包括：gopls、ARM 32 位、eval、信号、分析、go/packages api、重构、pprof、模块体验、单仓库分析、go 移动、依赖项、编辑器集成、编译器优化决策、调试、可视化、文档。很多人都对很多工具很感兴趣！

讨论集中在两个领域（时间允许）：gopls 和可视化。Gopls（发音：“go please”）是 Go 的语言服务器协议 (LSP) 服务器的实现。gopls 的主要作者 Rebecca Stambler 和 Go 工具团队的其他成员有兴趣了解人们使用 gopls 的体验：稳定性、缺少的功能、编辑器集成是否有效等等？总体感觉是 gopls 处于非常好的状态，并且在大多数用例中运行良好。需要改进集成测试覆盖率，但这对于跨所有编辑器“正确”地解决是一个难题。我们讨论了用户通过其编辑器报告遇到的 gopls 错误、遥测/诊断、gopls 性能指标的更好方法，所有这些主题在随后主要会议日期的 golang-tools 讨论中得到了更详细的介绍（见下文）。讨论的一个关键领域是如何扩展 gopls，例如，以 go/analysis vet 类检查、lint 检查、重构等形式。目前还没有好的解决方案，但正在积极研究中。谈话转向了非常广泛的可视化主题，Anthony Starks 进行了一次基于演示的介绍（顺便说一句，他在 2018 年 GopherCon 上发表了一个关于Go 用于信息显示的精彩演讲）。

大会日期。Go 工具相关的会议在主要大会日期举行，是自该小组在 2018 年 GopherCon 成立以来一直举办的每月电话会议的延续。完整记录可在第一天和第二天的会议记录中找到。这些会议再次获得了良好的参与度，每次会议都有 25-30 人参加。Go 工具团队全力参与（这表明该领域获得了良好的支持），Uber 平台团队也参与其中。与贡献者峰会相比，这些会议的目标是达成具体的行动项目。

Gopls。Gopls 的“准备就绪”是两个会议的主要焦点。这个问题实际上归结为确定何时告诉编辑器集成者“我们有一个良好的 gopls 初版”，然后编译一个已知可与 gopls 配合使用的“认可”编辑器集成/插件列表。此类编辑器集成/插件的“认证”的核心是用户可以报告他们在使用 gopls 时遇到的问题的明确流程。性能和内存对于这个初始“发布”来说不是障碍。关于如何扩展 gopls 的讨论在前一天的贡献者峰会上开始，并在本次会议中继续进行。尽管扩展 gopls 有许多明显的好处和吸引力（自定义 go/analysis 检查、代码风格检查支持、重构、代码生成……），但如何以可扩展的方式实现这一点尚无明确答案。与会者一致认为，这不应该被视为初始“发布”的障碍，但应该继续进行研究。本着 gopls 和编辑器集成的精神，Go 工具团队的 Heschi Kreinick 提出了调试支持的话题。Delve 已成为 Go 的事实上的调试器，并且状态良好；现在需要建立调试器-编辑器集成的状态，遵循与 gopls 和“认可”集成类似的流程。

Go 发现站点。第二个 golang-tools 会议由 Go 工具团队的 Julie Qiu 对 Go 发现站点进行了精彩的介绍，并进行了快速演示。Julie 谈到了发现站点的计划：开源该项目，搜索排名中使用的信号，godoc.org 最终将如何被取代，子模块应该如何工作，用户如何发现新的主要版本。

构建标签。然后，讨论转向了 gopls 中的构建标签支持。这是一个显然需要更好地理解的领域（用例目前正在issue 33389中收集）。鉴于此讨论，会议在 JetBrains GoLand 团队的 Alexander Zolotov 建议 gopls 和 GoLand 团队在这一领域以及更多领域分享经验后结束，因为 GoLand 已经积累了大量经验。

加入我们！我们本可以轻松地讨论数天与工具相关的主题！好消息是，golang-tools 电话会议将在可预见的未来继续进行。任何对 Go 工具感兴趣的人都被强烈鼓励加入：维基中有更多详细信息。

企业使用（Daniel Theophanes 的报告）

积极询问那些不善言辞的开发人员的需求将是 Go 语言面临的最大挑战，也是最大的胜利。有一大批程序员没有积极参与 Go 社区。有些人是业务伙伴、营销人员或质量保证人员，他们也从事开发工作。有些人会担任管理职位并做出招聘或技术决策。其他人只是完成自己的工作然后回家。最后，很多时候这些开发人员在拥有严格 IP 保护合同的企业工作。即使这些开发人员中的大多数最终不会直接参与开源或 Go 社区的提案，但他们使用 Go 的能力取决于两者。

Go 社区和 Go 的提案需要了解这些不善言辞的开发人员的需求。Go 的提案会对被采用和使用的内容产生重大影响。例如，vendor 文件夹和后来的 Go 模块代理对于严格控制源代码并且通常与 Go 社区进行较少直接对话的企业来说非常重要。拥有这些机制使这些组织能够使用 Go。由此可见，我们不仅要关注当前的 Go 用户，还要关注考虑过 Go 但最终没有选择它的开发人员和组织。我们需要了解这些原因。

同样，如果 Go 社区关注“企业”环境，它将为能够利用 Go 的许多其他组织打开大门。通过确保活动目录身份验证正常工作，那些被迫使用其他生态系统的用户可以继续考虑 Go。通过确保 WSDL 正常工作，一部分用户可以选择 Go 作为工具。没有人建议盲目地做出改变以取悦非 Go 用户。但我们应该意识到 Go 语言和生态系统中尚未开发的潜力和未被认识的障碍。

虽然讨论了从外部积极收集此信息的几种不同可能性，但这个问题从根本上需要你们的帮助。如果您所在的组织即使考虑过但也没有使用 Go，请告诉我们为什么没有选择 Go。如果您所在的组织仅将 Go 用于一部分编程任务，而没有用于其他任务，为什么不将其用于更多任务？采用 Go 是否存在特定的障碍？

教育（Andy Walker 的报告）

今年我在贡献者峰会上参与的一个圆桌会议的主题是 Go 教育，特别是我们为新的 Go 程序员提供了哪些资源，以及我们如何改进这些资源。出席会议的有许多充满激情的组织者、工程师和教育工作者，他们每个人都对该主题有独特的见解，无论是通过他们设计的工具、他们撰写的文档还是他们为各行各业的开发人员提供的研讨会。

在早期，讨论转向了 Go 是否适合作为第一门编程语言。我不确定，并反对这种观点。我认为 Go 不是一门好的第一门语言，因为它并非旨在成为第一门语言。正如 Rob Pike在 2012 年撰写的那样，“这门语言是由编写、阅读、调试和维护大型软件系统的人员设计并为他们设计的”。对我来说，这种指导理念很明确：Go 是对经验丰富的工程师使用的过程中感知到的缺陷的刻意回应，而不是试图创造一门理想的编程语言，因此假定了一定的编程概念的基本熟悉程度。

这在golang.org/doc上的官方文档中很明显。它直接跳到如何安装语言，然后将用户带到tour，该教程面向已经熟悉 C 类语言的程序员。从那里，他们会被带到如何编写 Go 代码，该文章对经典的非模块化 Go 工作区进行了非常基本的介绍，然后立即开始编写库和测试。最后，我们有Effective Go，以及一系列参考，包括规范，并辅以一些示例。如果您已经熟悉 C 类语言，那么这些都是不错的资源，但它们仍然有很多不足之处，并且对于新手甚至直接从 Python 等语言转过来的用户来说，没有任何东西可供参考。

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

对于经验丰富的程序员，应该对 tour 中的大多数部分进行可选的更深入的处理，使他们能够深入到更详细的文档或交互式练习中，这些文档或练习列举了 Go 中良好架构的设计决策原则。他们应该找到以下问题的答案

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

tour 应该是一个他们可以在第一次通读完成后重新访问的地方，以便更深入地研究语言设计中的一些更有趣的选项。

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

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

学习平台（Ronna Steinberg 的报告）

我们讨论了 Go 的学习平台应该是什么样子，以及如何结合全球资源来有效地教授这门语言。我们普遍认为，借助可视化，教学和学习更容易，并且 REPL 非常令人满意。我们还概述了一些使用 Go 进行可视化的现有解决方案：模板、Go WASM、GopherJS 以及 SVG 和 GIF 生成。

编译器错误对新开发人员来说毫无意义，这一点也被提了出来，我们考虑了如何处理它的想法，也许是一个错误库，以及它们将如何有用。一个想法是为编译器创建一个包装器，它会向你解释你的错误，并提供示例和解决方案。

后来又召集了一个新的小组进行第二轮讨论，我们更专注于 Go 学习平台应该拥有什么样的用户体验，以及我们是否以及如何从社区中获取现有的材料（演讲、博文、播客等）并将它们组织成人们可以从中学习的课程。这样的平台是否应该链接到那些外部资源？嵌入它们？引用它们？我们一致认为，门户式解决方案（外部资源的链接）使得导航变得困难，并且影响了学习体验，这使我们得出结论，这种贡献不可能是被动的，并且贡献者可能需要选择加入才能将其材料放到平台上。然后，人们对在平台上添加投票机制的想法非常兴奋，这实际上将学习者也变成了贡献者，并激励贡献者将他们的材料放到平台上。

（如果您有兴趣帮助 Go 的教育工作，请发送电子邮件给 Carmen Andoh [email protected]。）

感谢！

感谢所有参会者在贡献者日进行的精彩讨论，特别感谢 Lynn、Paul、Daniel、Andy 和 Ronna 抽空撰写这些报告。