2019-08-15 2019 年贡献者峰会

:::info 日期：2019 年 08 月 15 日
作者：Carmen Andoh and contributors
原文链接：https://go.dev/blog/contributors-summit-2019 :::

连续第三年，Go 团队和贡献者在 GopherCon 前一天召开会议，讨论和规划 Go 项目的未来。 该活动包括自组织分组，上午关于提案过程的市政厅式讨论，以及基于我们的贡献者选择的主题的下午分组讨论。 我们请五位贡献者写下他们在今年峰会的各种讨论中的经验。

(照片由史蒂夫法国。 )

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

Go 贡献者峰会是一个很好的机会，可以与其他为 Go 做出贡献的人会面并讨论主题和想法。

一天的开始是为了与房间里的每个人见面。 核心 Go 团队和其他积极为围棋做出贡献的人很好地组合在一起。 从那里我们决定感兴趣的主题以及如何将大组分成更小的组。 我感兴趣的领域是编译器，所以我加入了那个小组并且大部分时间都和他们在一起。

在我们的第一次会议上，提出了一长串主题，因此编译器小组决定全天继续开会。 我分享了一些我感兴趣的话题，其他人建议的许多话题也让我感兴趣。 并非清单上的所有项目都得到了详细讨论； 这是我最感兴趣和讨论最多的主题列表，然后是对其他主题的一些简短评论。

二进制大小。 有人对二进制文件的大小表示担忧，尤其是随着每个版本的发布，它会继续增长。 确定了一些可能的原因，例如增加内联和其他优化。 很可能有一组用户想要小二进制文件，另一组想要尽可能最好的性能，也许有些人并不关心。 这导致了 TinyGo 的话题，有人指出 TinyGo 不是 Go 的完整实现，重要的是要防止 TinyGo 与 Go 背道而驰并分裂用户群。 需要进行更多调查以了解用户的需求以及导致当前规模的确切原因。 如果有机会在不影响性能的情况下减小尺寸，则可以进行这些更改，但是如果性能受到影响，一些用户会更喜欢更好的性能。

矢量组装。 如何在 Go 中利用向量组装已经讨论了一段时间，并且在过去一直是一个有趣的话题。 我将其分为三种不同的可能性，因为它们都与向量指令的使用有关，但是它们的使用方式不同，从向量组装的主题开始。 这是编译器权衡的另一种情况。

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

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

在 Go 中利用向量指令的另一种方法是提供一种方法，可以更轻松地使用 Go 源代码中的向量指令。 讨论的主题是内在函数，或存在于其他编译器（如 Rust）中的实现。 在 gcc 中，一些平台提供内联 asm，Go 可能会提供这种功能，但我从经验中知道，将内联 asm 与 Go 代码混合会增加编译器在跟踪寄存器使用和调试方面的复杂性。 它允许用户做编译器可能不期望或不想要的事情，并且确实增加了额外的复杂性。 它可以插入不理想的地方。

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

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

一般优化。 讨论了对 x86 以外的某些平台更有益的某些优化。 特别是，可以完成诸如提升不变量和强度降低之类的循环优化，并在某些平台上提供更多好处。 讨论了潜在的解决方案，实施可能取决于认为这些改进很重要的目标。

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

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

编译时间问题。 简要讨论了编译时间。 注意到在 GOSSAFUNC 输出中添加了相位定时。

编译器贡献者交流。 有人问是否需要 Go 编译器邮件列表。 建议我们为此使用 golang-dev，将编译器添加到主题行以识别它。 如果 golang-dev 上的流量过多，则可以在稍后的某个时间点考虑使用特定于编译器的邮件列表。

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

工具(保罗·乔利的报告)

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

贡献者峰会。 工具会议首先收集了大约 25 个人的介绍，然后是头脑风暴主题，包括：gopls、ARM 32 位、eval、信号、分析、go/packages api、重构、pprof、模块体验、mono repo 分析、 移动、依赖、编辑器集成、编译器选择决策、调试、可视化、文档。 很多人对很多工具很感兴趣！

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

会议日。 主要会议日的 golang-tools 会议是自该小组在 GopherCon 2018 成立以来每月电话会议的延续。 第 1 天和第 2 天会议的完整笔记可用。 这些会议再次得到很好的参加，每次会议都有 25-30 人。 Go 工具团队实力雄厚（这是该领域支持的一个好兆头），优步平台团队也是如此。 与贡献者峰会相比，这些会议的目标是制定具体的行动项目。

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

Go Discovery Site。 第二个 golang-tools 会议以 Go 工具团队的 Julie Qiu 对 Go Discovery Site 的精彩介绍以及快速演示开始。 Julie 谈到了 Discovery Site 的计划：项目的开源、搜索排名中使用了哪些信号、godoc.org 最终将如何被替换、子模块应该如何工作、用户如何发现新的主要版本。

构建标签。 然后对话转移到在 gopls 中构建标签支持。 这是一个显然需要更好地理解的领域（目前正在问题 33389 中收集用例）。 鉴于这次谈话，会议结束时，来自 JetBrains GoLand 团队的 Alexander Zolotov 建议 gopls 和 GoLand 团队应该分享这方面和更多领域的经验，因为 GoLand 已经获得了很多经验。

加入我们！ 我们可以轻松地谈论与工具相关的话题好几天！ 好消息是 golang-tools 调用将在可预见的未来继续进行。 非常鼓励对 Go 工具感兴趣的任何人加入：wiki 有更多详细信息。

企业使用（Daniel Theophanes 的报告）

对于 Go 语言来说，积极询问较少发言的开发人员的需求将是最大的挑战，也是最大的胜利。 有很大一部分程序员没有积极参与 Go 社区。 有些是业务伙伴、营销人员或质量保证人员，他们也从事开发工作。 有些人会戴上管理帽子，做出招聘或技术决策。 其他人只是做好自己的工作，然后回到家人身边。 最后，很多时候这些开发人员在具有严格 IP 保护合同的企业中工作。 尽管这些开发人员中的大多数最终不会直接参与开源或 Go 社区提案，但他们使用 Go 的能力取决于两者。

Go 社区和 Go 提案需要了解这些不太会说话的开发人员的需求。 Go 提案会对采用和使用的内容产生很大影响。 例如，供应商文件夹和后来的 Go 模块代理对于严格控制源代码并且通常与 Go 社区的直接对话较少的企业非常重要。 拥有这些机制允许这些组织完全使用 Go。 因此，我们不仅要关注当前的 Go 用户，还要关注曾经考虑过但选择反对 Go 的开发人员和组织。 我们需要了解这些原因。

同样，如果 Go 社区关注“企业”环境，它将解锁许多可以使用 Go 的其他组织。 通过确保 Active Directory 身份验证有效，被迫使用不同生态系统的用户可以将 Go 保留在桌面上。 通过确保 WSDL 正常工作，一部分用户可以选择 Go up 作为工具。 没有人建议盲目做出改变来安抚非 Go 用户。 相反，我们应该意识到 Go 语言和生态系统中尚未开发的潜力和未被认识的障碍。

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

教育(安迪·沃克的报告)

今年我在贡献者峰会上参与的圆桌会议之一是关于 Go 教育的主题，特别是我们为新的 Go 程序员提供什么样的资源，以及我们如何改进它们。 出席的有许多非常热情的组织者、工程师和教育工作者，他们每个人都对这个主题有独特的看法，无论是通过他们设计的工具、他们编写的文档还是他们为各行各业的开发人员举办的研讨会。

早期，讨论转向 Go 是否是一种优秀的第一种编程语言。 我不确定，并主张反对。 我认为，Go 不是一门好的第一语言，因为它不是有意为之。 正如 Rob Pike 在 2012 年所写的那样，“该语言是由编写、阅读、调试和维护大型软件系统的人设计的，也是为他们设计的”。 对我来说，这种指导思想很明确：Go 是对经验丰富的工程师使用的流程中察觉到的缺陷的故意回应，而不是试图创建一种理想的编程语言，因此假设对编程概念有一定的基本熟悉。

这在 golang.org/doc 的官方文档中很明显。 在将用户介绍给已经熟悉 C 类语言的程序员之前，它直接介绍了如何安装该语言。 从那里，他们被带到如何编写 Go 代码，它提供了对经典非模块 Go 工作区的非常基本的介绍，然后立即开始编写库和测试。 最后，我们有 Effective Go，以及包括规范在内的一系列参考资料，并附有一些示例。 如果您已经熟悉类似 C 的语言，那么这些都是不错的资源，但它们仍然有很多不足之处，对于初学者甚至直接来自 Python 之类的语言的人来说，没有什么可以找到的。

作为一个可访问的、交互式的起点，导览自然是使语言对初学者更友好的第一个目标，我认为仅针对这一点就可以取得很多进展。 首先，它应该是文档中的第一个链接，如果不是 golang.org 顶部和中间的栏中的第一个链接。 我们应该鼓励好奇的用户直接进入并开始使用该语言。 我们还应该考虑包括可选的介绍部分，介绍来自其他常见语言的内容，以及他们在 Go 中可能遇到的差异，以及交互式练习。 这对于帮助新的 Go 程序员将他们已经熟悉的概念映射到 Go 有很大帮助。

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

• 当我大部分时间被鼓励使用 int 时，为什么有这么多整数类型？
• 是否有充分的理由选择价值接收者？
• 为什么有一个普通的 int，但没有普通的浮点数？
• 什么是只发送和只接收通道，我什么时候使用它们？
• 如何有效地组合并发原语，以及何时不想使用通道？
• uint 有什么用？ 我应该用它来限制我的用户使用正值吗？ 为什么不？

这次旅行应该是他们在完成第一次运行后可以重新访问的地方，以便更深入地了解语言设计中一些更有趣的选择。

但我们可以做得更多。 许多人寻求编程作为设计应用程序或解决特定问题的一种方式，并且他们最有可能希望针对他们最熟悉的界面：浏览器。 Go 还没有一个好的前端故事。 Javascript 仍然是唯一真正同时提供前端和后端环境的语言，但 WASM 正在迅速成为一阶平台，我们可以在很多地方使用它。 我们可以在 The Go Play Space 中提供诸如 vecty 之类的东西，或者针对 WASM 的 Gio，让人们立即开始在浏览器中编程，激发他们的想象力，并为他们提供一条从我们的操场迁移到终端并迁移到终端的路径 GitHub。

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

学习平台（Ronna Steinberg 报告）

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

还提出了对新开发人员没有意义的编译器错误，我们考虑了如何处理它的想法，也许是一堆错误以及它们如何有用。 一个想法是编译器的包装器，通过示例和解决方案向您解释您的错误。

稍后召集了一个新小组进行第二轮会议，我们更多地关注 Go 学习平台应该具有什么 UX，以及我们是否以及如何从社区中获取现有材料（演讲、博客文章、播客等）并将它们组织成一个 程序人可以借鉴。 这样的平台是否应该链接到那些外部资源？ 嵌入它们？ 引用它们？ 我们同意类似门户的解决方案（资源的外部链接）使导航变得困难并剥夺了学习体验，这使我们得出结论，这种贡献不能是被动的，贡献者可能不得不选择加入 将他们的材料放在平台上。 当时，在平台上添加投票机制、有效地将学习者也变成贡献者并激励贡献者将他们的材料放在平台上的想法引起了很多兴奋。

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

十分谢谢

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