2019 年 Go 贡献者峰会

未匹配的标注

本文为官方 Go Blog 的中文翻译,详见 翻译说明

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

介绍

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

(史蒂夫·弗朗西亚(Steve Francia)摄影。)

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

Go贡献者峰会是与为Go做出贡献的其他人讨论主题和思想的绝佳机会

当天开始是大家在一个房间里会面。Go的核心团队和其他为Go做出积极贡献的团队相处很融洽。我们决定了感兴趣的主题,以及如何将大集团划分为小集团。我感兴趣的领域是编译器,因此我加入了该小组而且大多数时间都与他们在一起。

在我们的第一次会议上,提出了很长的主题列表,结果,编译器小组决定全天继续开会。我分享了一些有趣的话题,其他人提出的许多话题也让我感兴趣。并未详细讨论列表中的所有项目。这是我最感兴趣和讨论的主题列表,然后是对其他主题的简短评论。

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

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

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

在Go中利用矢量指令的另一种方法是提供一种使在Go源代码中更容易使用矢量指令的方法。讨论的主题是内在函数,或其他编译器(如Rust)中存在的实现。在gcc中,某些平台提供了内联汇编,而Go可能提供了此功能,但是我从经验中知道,将内联汇编与Go代码混合在一起,会在跟踪寄存器使用和调试方面增加编译器的复杂性。它允许用户执行编译器可能不希望做的事情,并且确实增加了额外的复杂性。可以将其插入不理想的地方。

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

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

通用优化:讨论了某些对 x86 以外的平台更有利的优化。特别是,可以进行循环优化的,如不变量提升和强度降低,并在某些平台上提供更多好处。讨论了潜在的解决方案,实施可能要取决于发现这些改进很重要的目标。

反馈导向的优化:对此进行了讨论和辩论,认为这可能是将来的增强功能。以我的经验,很难找到有意义的程序来收集性能数据,这些数据以后可用于优化代码。它增加了编译时间,并占用了大量空间来保存数据,这可能仅对少量程序有意义。

待提交:该小组中的一些成员提到了他们正在准备提交的更改,包括对 makelice 的改进以及对 Rulegen 的重写。

编译时间的问题:简要讨论了编译时间。有人指出,可以在 GOSSAFUNC 的输出中增加了相位定时。

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

社区:我发现这一天非常有益,因为我可以与社区中活跃的、有相似兴趣领域的人交流。我遇到了很多人,我只知道他们的用户名出现在问题或邮件列表或 CL 中。我能够讨论一些话题和现有的问题,并获得直接的互动反馈,而不是等待在线回复。有人鼓励我写一些我所见过的问题。这种联系不仅发生在这一天,而且在整个会议期间遇到了其他的联系,第一天就介绍了这种联系,这导致了许多有趣的讨论。这些连接将在将来带来更有效的通信,并改进问题的处理和代码更改。

工具 (Paul Jolly 的报告)

贡献者峰会期间的工具分组会议采用了扩展形式,在 golang-tools 组组织的主要会议日又进行了两次会议。此摘要分为两部分:在贡献者研讨会上的工具会议,以及在主要会议日上来自 golang-tools 会议的合并报告。

贡献者峰会:工具会议从大约 25 个参与者的介绍开始,然后是集思广益的主题,包括:gopls,ARM 32-bit,eval,信号,分析,go / package api,重构,pprof,模块经验,mono repo 分析,移动,依赖性,编辑器集成,编译器选择决策,调试,可视化,文档。很多人对很多工具都感兴趣!

这次会议集中在两个领域(所有时间允许):gopls 和可视化。 Gopls (发音为「go please」)是语言服务器协议(LSP) Go 服务器的实现。 gopls 的主要作者 Rebecca Stamber 和 Go 工具团队的其他成员都对听取人们对 gopls 的体验感兴趣:稳定性,缺少的功能,在编辑器中的集成等?总体感觉是,gopls 的状态非常好,并且在大多数用例中都可以很好地工作。集成测试的覆盖率有待提高,但这是使所有编辑人员「正确」面对的难题。我们讨论了一种更好的方式,用户可以通过其编辑器报告遥测中遇到的 gopls 错误,遥测/诊断,gopls 性能指标以及所有主题,这些主题在随后的主要会议日的 golang-tools 会话中得到了更详细的介绍(请参阅下文)。讨论的关键领域是如何扩展 gopls,例如以额外的 go / analysis vet-like 检查,lint 检查,重构等形式。目前尚无好的解决方案,但正在积极研究中。对话转移到了非常广泛的可视化主题,安东尼·史塔克斯 (Anthony Starks) 进行了基于演示的介绍(顺便说一句,他很好地谈论了Go 信息显示 在 GopherCon 2018)。

会议日程:主要会议日的 golang-tools 会议是自 2018 年 GopherCon 大会成立以来的每月电话会议的延续。第 1 天第 2 天的会议有完整的笔记。这些会议每次都有 25-30 人参与。Go tools 团队实力雄厚(这是支持该领域的一个好迹象),Uber 平台团队也是如此。与贡献者峰会不同,这些会议的目标是提出具体的行动项目。

Gopls:Gopls 的「就绪」是这两次会议的重点。这个答案有效地归结为确定何时告诉编辑器集成商「我们对 gopls 的第一印象很好」,然后编制一个已知可与 gopls 一起使用的「幸运的」编辑器集成/插件的列表。编辑器集成/插件「认证」的核心是定义明确的过程,用户可以通过该过程报告其在 gopls 中遇到的问题。性能和内存不是此初始「发布」的障碍。前一天在贡献者峰会上开始了关于如何扩展 gopls 的讨论。尽管扩展 gopl 有很多明显的好处和吸引力(自定义 go /分析检查,lint 支持,重构,代码生成等),但是如何以可扩展的方式实现这一目标尚无明确答案。参会者一致认为,不应将其视为最初「发布」的障碍,而应继续努力。本着 gopls 和编辑器集成的精神,Go 工具团队的 Heschi Kreinick 提出了调试支持的主题。 Delve 已成为 Go 的调试器,并且状态良好。现在,需要按照类似于 gopls 和「幸运的」集成的过程来建立调试器与编辑器集成的状态。

Go Discovery 网站:第二个 golang-tools 会议上,Go tools 团队的 Julie Qiu 介绍了 Go Discovery 网站,并进行了快速演示。Julie 谈到了 Go Discovery 未来的计划:将项目开源,在搜索排名中使用信号,如何取代 godoc.org,子模块如何工作,用户如何发现新的版本。

构建标签:对话转向在 gopls 中构建标签支持。这个领域显然需要更好地理解(用例目前正在 issue 33389 中收集)。根据这次对话,此次会议与 JetBrains GoLand 团队的 Alexander Zolotov 进行了总结,建议 Gopls 和 GoLand 团队应该在此领域和更多领域分享经验,因为 GoLand 已经积累了很多经验。

加入我们!:我们可以一直谈论 tools-related 主题!好消息是,未来,我们会据徐支持 golang-tools。我们非常欢迎对 Go 工具感兴趣的人加入:Wiki 有更多详细信息。

企业的使用(Daniel Theophanes 的报告)

积极询问少言寡语的开发者的需求可能是 Go 语言最大的挑战,同时也将会是 Go 最大的收获。程序员之中有很大一部分并不会积极参与到 Go 社区之中。他们有些是商业合作伙伴、经销商、会参与开发的质量保证人员;有些担任着管理的职务,做着人事和技术的决策;有些不过是下班就回家的普通人。而这些人的工作常常受到严格的 IP 保护合同的限制。尽管这些开发者大多数不会直接参与到开源和 Go 社区提议的过程之中来,但这不影响他们使用依赖这两者的 Go 语言。

Go 社区和 Go 社区提议需要理解这些沉默的开发者的需要。Go 社区提议可能会对语言会采用什么、抛弃什么有很大的影响。比如供应商文件夹和之后的 Go 模块代理,对于严格控制源码的业务是非常重要的,这部分工作的参与者通常和 Go 社区直接交流会更少。这两种机制足够让参与这种工作的组织使用 Go 进行开发了。我们不能仅仅关注当前的 Go 用户的需求,还要注意到那些考虑使用 Go 语言但是最终没有选择 Go 的开发者和组织的需求。我们需要明白这种选择中的缘由。

类似的,Go 社区也应当关注「企业」环境,这样可以解锁许多会利用 Go 的新组织。如果保证活跃目录认证可用,那些被迫使用其他生态的用户仍然可以把
Go 放在手边;如果保证 WSDL 可用,就有一部分用户可以把 Go 当作一种工具。这绝对不是说为了取悦非 Go 用户盲目做修改,而是说我们要注意到那些 Go 语言和生态之中,未被识别的潜藏障碍。

尽管我们已经讨论了几种不同的向外索求这类信息的方法,但是这绝对是一个需要你们帮忙解决的问题。如果你在的组织考虑过使用 Go 但是最终没有选择它,请让知道知道为什么这样选。如果在你的组织之中恰恰选择了 Go 作为项目分项的开发工具,请让我们知道为什么没有用 Go 做更多。有明确的原因阻碍了你们吗?

教育(Andy Walker 的报告)

这些年我参与过的贡献者圆桌峰会是有关 Go 教育的,尤其是关于我们需要给刚接触 Go 的程序员提供什么样的资源,而我们如何提高资源质量。当时在场的是一些非常有热情的组织者、工程师和教育者,他们每一个都或者因为自己设计的工具,或者因为自己写过的文档,或者因为自己为各种各样的开发者提供的工作区……而对这一问题有着独特的视角。

后来,讲座转向了 Go 是否适合作为第一门程序语言。我对此没什么把握,随后我也做了相反方向的发言。我争论道,Go 不适合作为第一门语言,因为它本来就不打算是。如 Rob Pike 2012 年所写,「这门语言是为那些读或写、调试和维护大型软件系统的人设计的」。于我而言,有一个指导原则是非常清晰的:Go 是对有经验的开发者在使用流程之中发现的瑕疵作出的回应,而不是对创造理想化语言的尝试,所以语言之中才假设学习者已经对一些基本的编程概念熟悉。

这在官方的文档 golang.org/doc 这也是非常明显的。文档在让读者学习 Go 语言之旅 之前就切入到如何安装语言。这样的排布是非常适合已经熟悉类 C 语言的程序员的。紧随其后是 如何书写 Go 代码,这在大家进行库开发和测试之前,提供了对经典非模块 Go 工作区的介绍。最后是 高效的 Go,和一系列包括 语言规范 在内的参考文档,还有一些例子。如果你已经熟悉类 C 语言,这些都是非常恰当的资料了,不过还是不能满足所有人的需求,这其中也没有为全新的编程入门者——哪怕是那些直接从 Python 切换过来的人——提供学习资源。

作为一个可行的措施,一个交互式的起跑点。Go 语言之旅是让语言对新手更加友好的一个自然出发点,而我认为有很多方法可以针对这一项达成目的。首先,它应该被放在文档页链接的第一个,不然的话就作为 golang.org 页顶栏前面或者中央的链接也可以。我们应该鼓励好奇的用户直接开始动手玩弄这门语言。同时,我们应该加上从其他常见语言迁移的可选的介绍小节,配合交互式的练习,介绍他们可能在 Go 之中遇上的不同点。这样可以帮助 Go 语言新手把以前学习过的概念对应到 Go 之中来。

对于那些编程老手,大多数小节需要加入一个可选的、更深层次的的内容。这样他们可以向那些列举良好设计决策与原则的交互练习或者文档之中深挖更多细节。这批人最终应该要能回答像是这样的问题:

  • 为什么有那么多整数类型,为什么大多数时候我应该用 int
  • 什么动机驱使我选择值接收器?
  • 为什么有无修饰的 int 但是没有无修饰的 float
  • 仅接受和仅发送信道是什么?什么时候应该用他们?
  • 我怎样高效地整合并发原型,什么时候我 不应该 使用信道?
  • uint 有什么好处?我应该使用这样的类型限制用户使用正值吗?为什么不呢?

Go 语言之旅应该是一个在他们结束了概览之后,可以为了挖掘更多语言设计之中有趣的选择而重读的内容。

但是我们可以做得更好。许多人把编程当作是设计应用的方式或者只是为了解决某一种特定的欲望,这些人可能会最乐意选择他们最熟悉的界面:浏览器。Go 还没有比较好的前端支持。Javascript 仍然是唯一同时提供前后端环境的语言,不过 WASM 正在快速发展为第一阶层的平台,有了这一个辅助我们可以做很多事情。我们可以提供像是  The Go Play Space 里 vecty 的东西。或者让大家能够立即在浏览器里编程,指向 WASM 的 Gio 来激发他们的想象力,同时也给他们指明从我们的演练场迁移到终端或者 Github 的道路。

那么,Go 适合当第一门语言吗?实话说,我不太清楚。但是确实有人把 Go 当作他们进入职业编程的起点,我也很有兴趣和他们聊聊了解他们在这一路上的经历,利用他们的叙述更好的塑造 Go 教育未来的样子。

学习平台(Ronna Steinberg 的报告)

我们讨论了 Go 的学习平台应该是什么样子和我们如何通过整合全局资源来让语言教授过程更高效。我们基本同意可视化的内容可以让教和学都更加容易,同时 REPL 是不错的选择。我们重新审视了一些现存的 Go 可视化方案:模版、Go WASM、Gohper JS 和 SVG 与 GIF 的生成。

新开发者无法看懂编译器错误提示的问题也被讨论了,我们思考了解决的方案,比如错误信息和分析的汇总。一个方案是给编译器加一个外壳,用来解释各个错误,同时提供例子和解决方案。

接下来一个新的小组开展了第二轮讨论,聚焦在 Go 学习平台的 UX 上,以及我们如何将社区的既有内容(演讲、博文、博客等等)组织成一个可以用于学习的资料。这样的一个平台要使用链接式?嵌入式?还是标注引用式?来跳转到这些外部资源。我们都认为创建(外部资源)门户的模式会让浏览变得很难受,同时影响到了学习体验。这最终把我们引向这样一个结论:这种贡献不能是被动的,贡献者可能需要主动选择将自己的内容发布的平台上。随后便有了给平台加上投票系统这样激动人心的方案。这样既有效地把学习者也变成了贡献者,也激励贡献者将自己的内容发布到平台上。

(如果你有兴趣助力 Go 在教学上的努力,请发邮件给 Carmen Andoh candoh@google.com。)

谢谢大家!

感谢所有参与这场漂亮的讨论的贡献者们,尤其是感谢 Lynn、Paul、Daniel、Andy 和 Ronna 花时间写这些报告。

本文章首发在 LearnKu.com 网站上。

本译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。

原文地址:https://learnku.com/docs/go-blog/contrib...

译文地址:https://learnku.com/docs/go-blog/contrib...

上一篇 下一篇
Summer
贡献者:4
讨论数量: 0
发起讨论 只看当前版本


暂无话题~