Go 博客

2019 贡献者峰会

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

引言

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

(图片由 Steve Francia 拍摄。)

编译器和运行时 (Lynn Boger 报告)

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

会议伊始，大家进行了自我介绍。核心 Go 团队成员与其他积极贡献 Go 的人员混合得很好。接着，我们决定了感兴趣的主题，并将大组分成了小组。我的兴趣领域是编译器，所以我加入了那个小组并大部分时间都留在那里。

在我们的第一次会议上，提出了很多主题，因此编译器小组决定全天继续开会。我分享了一些感兴趣的主题，许多其他人提出的主题我也很感兴趣。列表上的所有项目都没有详细讨论；这是我列出的那些最受关注和讨论的主题，后面是一些关于其他主题的简要评论。

二进制文件大小。有人对二进制文件大小表示担忧，特别是它在每个版本中持续增长。确定了一些可能的原因，例如增加了内联和其他优化。很有可能有一部分用户想要小的二进制文件，另一部分用户想要尽可能好的性能，也许有些人不在乎。这引出了 TinyGo 的话题，并指出 TinyGo 不是 Go 的完整实现，并且重要的是要防止 TinyGo 与 Go 分离并分裂用户基础。需要进一步调查以了解用户的需求以及导致当前大小的确切原因。如果在不影响性能的情况下有机会减小大小，可以进行这些更改，但如果影响性能，一些用户会更喜欢更好的性能。

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

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

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

在 Go 中利用向量指令的另一种方法是提供一种方式，使在 Go 源代码中使用向量指令更加容易。讨论的主题包括 intrinsics，或者其他编译器（如 Rust）中存在的实现。在 gcc 中，某些平台提供 inline asm，Go 可能也可以提供此功能，但我从经验得知，将 inline asm 与 Go 代码混合会增加编译器在跟踪寄存器使用和调试方面的复杂性。它允许用户做编译器可能不期望或不想做的事情，并且确实增加了额外的复杂性。它可能被插入到不理想的地方。

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

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

通用优化。讨论了一些对 x86 以外的某些平台更有益的优化。特别是，可以进行循环优化，例如不变量外提和强度削减，并在某些平台上提供更多收益。讨论了潜在的解决方案，其实现可能取决于认为这些改进很重要的目标平台。

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

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

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

编译器贡献者交流。有人问是否需要一个 Go 编译器邮件列表。建议为此目的使用 golang-dev 邮件列表，在主题行中添加“compiler”以便区分。如果 golang-dev 的流量过大，可以在稍后考虑设立一个针对编译器的邮件列表。

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

工具 (Paul Jolly 报告)

贡献者峰会期间的工具分组讨论采取了扩展形式，在主会议日又增加了由 golang-tools 小组组织的两次会议。本总结分为两部分：贡献者研讨会上的工具会议，以及主会议日 golang-tools 会议的综合报告。

贡献者峰会。工具会议由聚集的约 25 人自我介绍开始，随后是主题头脑风暴，包括：gopls、ARM 32 位、eval、signal、analysis、go/packages api、refactoring、pprof、模块体验、mono repo 分析、go mobile、依赖项、编辑器集成、编译器优化决策、调试、可视化、文档。许多人对许多工具都充满兴趣！

会议主要聚焦于两个领域（时间允许的情况下）：gopls 和可视化。Gopls（发音类似：“go please”）是 Go 语言服务器协议 (LSP) 服务器的实现。gopls 的主要作者 Rebecca Stambler 和其他 Go 工具团队成员很想听听大家使用 gopls 的经验：稳定性、缺失功能、编辑器集成是否正常工作等等？普遍的感觉是 gopls 状态良好，并且在大多数用例中运行得非常好。需要改进集成测试覆盖率，但这对于所有编辑器来说都是一个难题。我们讨论了用户通过编辑器报告遇到的 gopls 错误、遥测/诊断、gopls 性能指标的更好方法，这些都是在主会议日举行的 golang-tools 会议中更详细讨论的主题（见下文）。一个关键的讨论领域是如何扩展 gopls，例如，以额外的 go/analysis 检查、lint 检查、重构等形式。目前还没有好的解决方案，但正在积极调查中。对话转向了非常广泛的可视化主题，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 工具感兴趣的人加入：维基页面有更多详细信息。

企业应用 (Daniel Theophanes 报告)

主动关注不那么发声的开发者的需求，将是 Go 语言面临的最大挑战，也是最大的胜利。有很大一部分程序员不积极参与 Go 社区。其中一些是商务人士、市场人员或质量保证人员，他们也从事开发工作。有些人会担任管理职务，负责招聘或技术决策。其他人只是做好自己的工作，然后回到家人身边。最后，很多时候这些开发者在具有严格知识产权保护合同的企业工作。即使这些开发者中的大多数最终不会直接参与开源或 Go 社区的提案，他们使用 Go 的能力取决于这两者。

Go 社区和 Go 提案需要理解这些不那么发声的开发者的需求。Go 提案对哪些内容被采用和使用具有重大影响。例如，vendor 文件夹以及后来的 Go modules proxy 对于严格控制源代码且通常与 Go 社区直接交流较少的企业来说至关重要。正是这些机制使得这些组织能够使用 Go。因此，我们不仅要关注当前的 Go 用户，还要关注那些曾考虑过 Go 但最终选择放弃的开发者和组织。我们需要了解这些原因。

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

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

教育 (Andy Walker 报告)

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

很早的时候，讨论转向了 Go 是否适合作为第一门编程语言。我不确定，并且主张反对。我认为 Go 不是一门好的第一门语言，因为它本就不是为此设计的。正如 Rob Pike 在 2012 年所写，“这门语言是由编写、阅读、调试和维护大型软件系统的人设计并为他们服务的”。对我来说，这种指导思想很明确：Go 是对有经验的工程师使用的过程中感知到的缺陷的刻意回应，而不是试图创建一个理想的编程语言，因此它假定用户对编程概念有一定的基本了解。

这在 golang.org/doc 上的官方文档中很明显。它直接跳到如何安装这门语言，然后将用户引导至入门教程，该教程面向已经熟悉 C 语言的程序员。从那里，他们被引导到如何编写 Go 代码，它提供了经典非模块 Go 工作区的一个非常基础的介绍，然后立即转向编写库和测试。最后，我们有高效 Go，以及一系列参考资料，包括规范，并附带一些示例。如果您已经熟悉 C 语言，这些都是不错的资源，但它们仍有许多不足之处，对于完全的初学者或甚至直接从 Python 等语言转过来的开发者来说，找不到什么适合的内容。

作为易于访问的交互式起点，入门教程是使语言对初学者更友好的天然首选目标，我认为仅针对这一点就可以取得很大进展。首先，它应该是文档中的第一个链接，如果不是 golang.org 顶部导航栏的第一个链接，也应该放在显眼位置。我们应该鼓励好奇的用户立即开始尝试和使用这门语言。我们还应该考虑加入可选的介绍性章节，介绍从其他常见语言转过来的用户在 Go 中可能遇到的差异，并附带交互式练习。这将极大地帮助新的 Go 程序员将他们已经熟悉的概念映射到 Go 上。

对于有经验的程序员，入门教程的大多数章节应该提供可选的更深入的阐述，允许他们深入研究更详细的文档或交互式练习，这些练习可以列举 Go 中良好架构的设计决策原则。他们应该找到以下问题的答案：

• 为什么当大多数时候鼓励我使用 int 时，却有这么多整数类型？
• 是否有充分的理由选择值接收者？
• 为什么有基本的 int 类型，却没有基本的 float 类型？
• 什么是仅发送和仅接收通道，我什么时候会使用它们？
• 我如何有效地组合并发原语，以及什么时候我不应该使用通道？
• uint 有什么用处？我应该用它来限制用户只能输入正数吗？为什么不？

入门教程应该是一个他们完成第一遍学习后可以重访的地方，以便更深入地探讨语言设计中一些更有趣的选择。

但我们可以做得更多。许多人将编程视为设计应用程序或解决特定问题的途径，他们最可能想针对他们最熟悉的界面：浏览器。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: candoh@google.com。）

谢谢！

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