原文:https://blog.golang.org/go2-here-we-come

背景

在2017年的GopherCon上，Russ Cox正式开始关于Go的下一个大版本的思考过程，他的演讲是The Future of Go （博客文章）。我们已经非正式地将这种未来语言称为Go 2，即使我们现在明白它将以渐进的步骤到达，而不是通过大爆炸和单个主要版本。尽管如此，Go 2仍然是一个有用的绰号，如果只是想谈谈未来的语言，那么让我们继续使用它。

Go 1和Go 2的主要区别在于谁将影响设计以及如何做出决策。Go 1是一个小团队的努力，外部影响不大; Go 2将更加受社区驱动。经过近10年的曝光，我们学到了很多关于我们一开始就不知道的语言和图书馆的知识，而这只能通过Go社区的反馈来实现。

2015年，我们介绍了提案流程， 以收集特定类型的反馈：语言和图书馆变更提案。由Go高级团队成员组成的委员会一直在定期审查，分类和决定提交的提案。这非常有效，但作为该过程的一部分，我们忽略了所有不向后兼容的提案，只需将它们标记为Go 2。2017年，我们也停止进行任何类型的渐进式向后兼容语言更改，无论多么小，都支持更全面的计划，将Go 2的大局考虑在内。

现在是采取行动2提案的时候了，但要做到这一点，我们首先需要一个计划。

状态

在撰写本文时，大约有120个 标记为Go 2提案的未决问题。它们中的每一个都提出了重要的库或语言更改，通常是不满足现有 Go 1兼容性保证的库。伊恩兰斯泰勒和我一直在研究这些建议并对它们进行分类（Go2Cleanup， NeedsDecision等）以了解它们的含义并使其更容易进行。我们还合并了相关的提案，并关闭了那些看似明显超出Go范围的提案，或者其他方面无法实现的提案。

其余提案中的想法可能会影响Go 2的图书馆和语言。早期出现了两个主要主题：支持更好的错误处理和泛型。这两个领域的设计草案已在今年的GopherCon上发布，需要进行更多的探索。

但其余的呢？我们 现在拥有数以百万计的Go程序员和大量的Go代码，我们受到限制，我们需要将其全部带入，以免冒险分裂生态系统。这意味着我们不能做出很多改变，我们要做的改变需要仔细选择。为了取得进展，我们正在为这些重大的潜在变化实施新的提案评估流程。

提案评估流程

提案评估过程的目的是收集关于少数选定提案的反馈，以便做出最终决定。该过程或多或少地与发布周期并行运行，并包含以下步骤：

1. 提案选择。Go团队选择了少量 似乎值得考虑接受的 Go 2提案，而没有做出最终决定。有关选择标准的更多信息，请参见下文。

2. 提案反馈。Go团队发出一份列出所选提案的公告。该公告向社群解释了推进所选提案的初步意图，并收集了每个提案的反馈意见。这使社区有机会提出建议并表达关切。

3. 实施。根据这些反馈，提案得以实施。这些重要语言和库更改的目标是让它们准备好在即将发布的发布周期的第1天提交。

4. 实施反馈。在开发周期中，Go团队和社区有机会尝试新功能并收集进一步的反馈。

5. 启动决定。在三个月开发周期结束 时（只是在发布之前开始三个月的回购冻结），并根据在发布周期中收集的经验和反馈，Go团队做出关于是否发送每个更改的最终决定。这提供了一个机会来考虑变更是否已实现预期收益或产生任何意外成本。发布后，更改将成为语言和库的一部分。被排除的提案可能会回到绘图板或可能会被拒绝。

通过两轮反馈，这个过程倾向于拒绝提议，这有望防止功能蔓延，并有助于保持语言小而干净。

对于每个开放的Go 2提案，我们都无法完成这个过程，其中有太多。这就是选择标准发挥作用的地方。

提案选择标准

提案必须至少：

1. 为许多人解决一个重要问题，

2. 对别人的影响微乎其微，并

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

要求1确保我们所做的任何更改都能帮助尽可能多的Go开发人员（使他们的代码更健壮，更容易编写，更可能是正确的等等），而需求2确保我们小心谨慎可能，无论是通过打破他们的程序或导致其他流失。根据经验，我们的目标应该是帮助至少十倍于开发人员，因为我们在给定的变化时会受到伤害。不影响真实Go使用的变化是针对重大实施成本的净零利益，应该避免。

如果没有要求3，我们就没有提案的实施。例如，我们认为某种形式的通用性可能会为很多人解决一个重要问题，但我们还没有一个明确且易于理解的解决方案。这没关系，只是意味着提案需要在可以考虑之前回到绘图板。

建议

我们认为这是一个很好的计划，应该很好地为我们服务，但重要的是要明白这只是一个起点。在使用该过程时，我们将发现它无法正常工作的方式，我们将根据需要对其进行优化。关键部分是，在我们实际使用它之前，我们不知道如何改进它。

一个安全的起点是使用少量向后兼容的语言提议。我们很长一段时间没有进行语言更改，所以这让我们回到了那种模式。此外，这些变化不需要我们担心破坏现有代码，因此它们可以作为一个完美的试验气球。

尽管如此，我们建议为Go 1.13版本（提案评估过程中的第1步）选择Go 2提案：

1. ＃20706 基于 Unicode TR31的通用Unicode标识符：这解决了使用非西方字母表的Go程序员的一个重要问题，并且对其他任何人都应该没什么影响。我们需要回答归一化问题以及社区反馈意义重要，但在此之后，实施路径得到了充分理解。请注意，标识符导出规则不受此影响。

2. ＃19308，＃28493 二进制整数文字和对数字文字的支持：这些是相对较小的变化，在许多程序员中似乎非常受欢迎。他们可能还没有达到解决“重要问题”的门槛（到目前为止，十六进制数字运行良好），但是在这方面，它们使Go与大多数其他语言相提并论，并减轻了一些程序员的痛点。它们对不关心二进制整数文字或数字格式的其他人的影响很小，并且实现很好理解。

3. ＃19113 允许有符号整数作为移位计数：估计所有非常数移位中有38％需要（人工）uint转换（请参阅问题以获得更详细的细分）。这个提议将清理很多代码，使得表达式表达式更好地与索引表达式和内置函数cap和len同步。它将主要对代码产生积极影响。实施很好理解。

下一步

通过这篇博客文章，我们执行了第一步，并开始了提案评估流程的第二步。现在，由Go社区提供有关上述问题的反馈。

对于我们已经明确并批准反馈的每个提案，我们将继续实施（流程中的第3步）。因为我们希望在下一个发布周期的第一天（暂定于2019年2月1日）实施更改，所以我们可能会在这个时间稍早开始实施，以留出两个月的反馈时间（2018年12月，2019年1月） ）。

对于为期3个月的开发周期（2019年2月至5月），所选功能已经实施并在小费处可用，每个人都有机会收集它们的经验。这为反馈提供了另一个机会（过程中的第4步）。

最后，在回购冻结后不久（2019年5月1日），Go团队最终决定是否保持新功能（并将其包含在Go 1兼容性保证中），或者是否放弃它们（最后一步）过程）。

（因为在我们冻结回购时很可能需要删除某个功能，所以实现将需要禁用该功能而不会破坏系统其他部分的稳定性。对于语言更改可能意味着所有与功能相关的代码都由内部标志保护。）

这将是我们第一次遵循这一过程，因此回购冻结也将是反思过程并在必要时进行调整的好时机。让我们看看它是怎么回事。