对Go存严重误导，Go开发团队leader怒驳AWS

Posted 2022-02-27 OSC开源社区

文 | 局长

出品 | OSC开源社区（ID：oschina2013）

事件起因是 AWS 前几天发布的一篇博客：《Sustainability with Rust》。

博客原文：https://aws.amazon.com/cn/blogs/opensource/sustainability-with-rust/

在这篇文章里，AWS 举例的时候将 Rust 和 Go 进行了对比。文章提到了早期 Discord 的一项关键 Go 服务存在问题，原本这是一个非常简单的服务，但它的尾部延迟 (Tail Latency) 非常慢。AWS 认为原因在于 Go 是一种垃圾回收 (GC) 语言，因此当对象被创建和释放时，垃圾回收器每隔一段时间就需要停止程序的执行并运行一次垃圾回收。当垃圾回收器运行时，会导致进程无法响应请求。

为了解决此问题，Discord 决定尝试用 Rust 重写这个服务。测试结果显示，使用 Rust 重写后的速度提升超 10 倍，最慢的尾部延迟时间也降低至为原来的约 1%。

下图是运行过程中 CPU 和响应时间的峰值，左边为 Go 实现的版本，右边为 Rust 实现的版本。

Go 开发团队 leader Russ Cox (rsc) 认为 AWS 在这里的比较对 Go 存在严重的误导。他认为，AWS 的文章将两者进行对比时，将 Go 版本的数据与在使用新的数据结构和更多内存后的 Rust 版本数据放在了一起，还特意圈出“ms”和“µs”时间刻度。rsc 表示，这要么是 AWS 对 Discord 的原贴存在误解，要么就是公然地说谎。

因为在 Discord 的原文中，他们展示 Go 服务器和同级别 Rust 服务器的对比时，图表数据来源既有原始的版本，也包括重写数据结构和提供额外内存后的情况。AWS 的文章却对此进行了故意的歪曲。

而且 AWS 引用的 Discord 数据当时使用的 Go 版本还是 Go 1.10，但现在 1.18 版本很快就推出了。在这 8 个重要版本的迭代过程中，Go 团队改进了许多功能，对因 GC 而引起的中断也提供了极大的改善（这正是当时 Discord 面临的问题）。

除了这个，rsc 认为 AWS 引用的一份“非常有趣”的研究的真实性也十分可疑。

rsc 表示，AWS 的文章对 Rust 的描述公正客观，但对 Go 却存在误导性的描述。他认为 Rust 和 Go 不是零和的博弈关系。Rust 十分优秀，所以他更愿意关注 Go 和 Rust 相互补充并进行良好合作的方式。比如这个案例：https://thenewstack.io/rust-vs-go-why-theyre-better-together/

往期精彩回顾

马斯克：我是Rust粉丝，但为了性能会选择C

16K Star，「程序员做饭指南」冲上热榜

被侮辱、被架空，Swift之父退出核心团队

觉得不错，请点个在看呀

Go 语言的下一个大版本：Go 2.0 被安排上了！

今年 8 月 Go 开发团队公布了 Go 2.0 的设计草案，包括错误处理和泛型这两大主题。现在备受瞩目的 Go 2.0 又有了新动向 —— 昨日 Go 开发团队在其官方博客表示，Go 2 已经被安排上了！目前 Go 2 已进入确定变更提案的阶段，并公布了提案评估流程。

废话不多说，先来看看 Go 2.0 有哪些值得关注的内容：

1.最大程度保持对 1.x 的兼容，以避免分裂 Go 语言生态系统

2.采用增量升级的方式，而非单独发布重大更新版本

3.实施新的提案评估流程，以评估尚未解决且被标记为提案的 issue

4.将会在 Go 1.13 版本中选择 Go 2 部分的提案

背景

早在2017年的 GopherCon 大会上，Russ Cox（Go 核心开发团队的技术 leader）就已经正式开始思考 Go 的下一个大版本（相关文章）。当时官方非正式地将它称为 Go 2，但我们知道，所谓的 Go 2.0 并非一个单独的重大更新版本，而是通过“增量更新(incremental)”的方式以逐渐抵达 "Go 2.0"。所以本文对这个未来版本的称号 —— 也暂且用 Go 2 来描述。

Go 1 和 Go 2 之间的主要区别在于主导权的不同。谁将影响设计，又该如何做出决策？我们都知道，Go 1 的诞生是小团队努力的结果，受外部影响不大；而到了 Go 2，尤其是经过将近 10 年的发展后，Go 语言的生态已经十分庞大，因此它也更多地受到社区的驱动和影响。经历了这些，Go 开发团队也了解到了更多一开始不知道的与语言特性和库相关的知识 —— 这些都来自于 Go 社区的反馈。

2015年，Go 开发团队引入了提案流程，以收集特定类型的反馈：针对语言和库变更方面的提案。由 Go 开发团队高级成员组成的委员会定期审查、分类和决定社区提交的提案。这个流程十分有效，但作为该过程的一部分，他们忽略了所有不向后兼容的提案，只是将其标记至 Go 2。到了2017年，Go 开发团队也停止进行任何类型的向后兼容的“增量”语言特性变更，因为他们认为无论变更多么小，都要有更全面的支持计划，并将 Go 2 考虑在内。

对于这些累积下来的提案，官方表示现在是时候采取行动了！

近况

本文发布时，官方表示目前在 Go 2 的提案中，大约有 120 个尚未解决且被标记为提案的 issue。这些提案都涉及到重要的库或语言特性变更，而它们通常不能与 Go 1 互相兼容。Ian Lance Taylor 和 Robert Griesemer 一直在研究这些提案，并对它们进行了分类(Go2Cleanup, NeedsDecision 等)，以理解这些提案背后的含义并使它们后续更易进行。此外，他们还合并了相似的提案，并关闭了那些看似明显超出 Go 范围的提案，或者其他方面无法实现的提案。

早期出现的两个提案包括更好的错误处理和泛型，而它们的草案已在今年的 GopherCon 大会上发布，等待更多的探索发展。至于剩余的提案，官方提到，他们不希望过度影响数百万 Go 开发者以及现在的 Go 代码，更不想冒着分裂生态系统的风险去改版 Go 2，因此 Go 2 无法做出太多变更，每一个变更都需要仔细选择。为此，这些提案都将使用新的提案评估流程来决定去留与发展。

提案评估流程

提案评估流程旨在收集对少数选定提案的反馈意见，以作出最终决定。这个过程或多或少会与发布周期并行进行，包括以下步骤：

1. 提案选择：Go 开发团队选择少量看起来值得考虑接受的 Go 2 提案，但尚未做出最终决定。

1. 提案反馈：Go 开发团队将发布一份列出所选提案的公告，公告会向社区解释提案的初衷并收集反馈意见。在这个步骤中，社区可提出建议。

1. 实现：根据来自社区的反馈意见，提案开始实现。

1. 针对所实现的提案的反馈：在开发周期中，Go 开发团队和社区试用新功能并且收集进一步的反馈意见。

1. 启动决策：在三个月的开发周期结束时，根据在发布周期中收集的经验和反馈意见，Go 开发团队会考虑变更的预期收益或产生的额外成本，从而最终决定是否发布每个变更。一旦发布，这些被发布的提案就成为语言和库的一部分。未被发布的提案可能会重新起草，但也有可能会被永久拒绝。

可以看到，通过两轮的反馈过程，可对提案进行有效的筛选，从而防止“功能蔓延(feature creep)”，有助于保持 Go 语言的简洁。

提案选择标准

一项提案至少要满足以下这些条件：

1. 解决大部分使用者觉得重要的问题

1. 不会对其他使用者造成太大的影响

1. 提供一个清晰且易于理解的解决方案

条件1确保提案所做的任何变更都可以帮助到尽可能多的 Go 开发者（使他们编写的代码更健壮、正确性更高等），条件2则保证了变更将给使用者带来的影响降到最低。

至于条件3，如果提案不能满足该条件，它将不会被实现。即便这项提案能够解决一个很重要的问题，思路也很好，但在没有实现方案的情况下，它将会被拒绝，并需要重新起草。

下一步

在这篇文章发布时，Go 开发团队表示已经执行提案评估流程的第一步，并开始了流程的第二步，关于具体的提案可点此进行查看。

对于 Go 开发团队已经明确并通过的提案，将会继续实现（即评估流程的第3步）。开发团队表示希望在下一个发布周期的第一天（暂定于2019年2月1日）完成这些提案变更的实现，所以这次可能会在较早的时间开始进行，以留出两个月的反馈时间（2018年12月至2019年1月）。

而在为期3个月的开发周期中（2019年2月至5月），被选择的提案将会被实现，每位使用者都可以体验新功能并进行反馈（评估流程的第4步）。

最后，在短暂的冻结期后（2019年5月1日），Go 开发团队会最终决定是否永久保留新功能（并保证这些功能与 Go 1 兼容），或是放弃这些功能（评估流程的最后一步）。

Go 开发团队表示这是首次采用这一流程，因此在冻结阶段将会是反思这个流程，并在必要时进行调整的好机会。我们也不妨拭目以待吧！

开源中国征稿开始啦！

开源中国 www.oschina.net 是目前备受关注、具有强大影响力的开源技术社区，拥有超过 200 万的开源技术精英。我们传播开源的理念，推广开源项目，为 IT 开发者提供一个发现、使用、并交流开源技术的平台。

现在我们开始对外征稿啦！如果你有优秀的技术文章想要分享，热点的行业资讯需要报道等等，欢迎联系开源中国进行投稿。投稿详情及联系方式请参见：

推荐阅读

更多详情请查看阅读原文↓↓↓↓↓