|
以下为你解析 Go 语言的下代更新版本：Go 2.0，它做为一个重大的版本，将会有很多新的更新。Go 开发团队已经宣布 Go 2 已被安排上了，目前 Go 2 已进入确定变更提案的阶段，并公布了提案评估流程。其实早在 2018 年 8 月份时 Go 开发团队就公布了 Go 2.0 的设计草案，包括错误处理和泛型这两大主题。以下将介绍 Go 2.0 语言值得关注的内容及其新动向。
将不完全向后兼容 Go 1.X Go 2 的目标就是解决 Go 1 在规模化方面做的还不好的地方。 如果把 Go 2 要增加的特性分为兼容部分和不兼容部分，具体思路如下： 先按照 Go 1 的版本发布计划，增量式交付兼容的部分，一个特性一个特性地加进来。在完成了所有向后兼容的工作后，再考虑在此基础上开发 Go 2 的不兼容部分。比如说，在 Go 1.2 版本的基础之上加上 Go 2 的不兼容部分，没问题后，直接将 Go 1.2 命名为 Go 2.0。
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 提案，但尚未做出最终决定。 2.提案反馈：Go 开发团队将发布一份列出所选提案的公告，公告会向社区解释提案的初衷并收集反馈意见。在这个步骤中，社区可提出建议。 3.实现：根据来自社区的反馈意见，提案开始实现。 4.针对所实现的提案的反馈：在开发周期中，Go 开发团队和社区试用新功能并且收集进一步的反馈意见。 5.启动决策：在三个月的开发周期结束时，根据在发布周期中收集的经验和反馈意见，Go 开发团队会考虑变更的预期收益或产生的额外成本，从而最终决定是否发布每个变更。一旦发布，这些被发布的提案就成为语言和库的一部分。未被发布的提案可能会重新起草，但也有可能会被永久拒绝。 可以看到，通过两轮的反馈过程，可对提案进行有效的筛选，从而防止“功能蔓延(feature creep)”，有助于保持 Go 语言的简洁。
提案选择标准 一项提案至少要满足以下这些条件： 1.解决大部分使用者觉得重要的问题。 2.不会对其他使用者造成太大的影响。 3.提供一个清晰且易于理解的解决方案。 条件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 开发团队表示这是首次采用这一流程，因此在冻结阶段将会是反思这个流程，并在必要时进行调整的好机会。我们也不妨拭目以待吧。
相关主题 |
