蛰伏5年，Go Language 2.0 终于要来了！
早在今年8月份，Go团队便提出了2.0版本的设计草案，包括两大主题：错误处理和泛型。而今天，团队开发人员发话了：“是时候采取行动了！”
Go 1和Go 2主要的区别在于决策的制定——Go 1的诞生是一个小团队的努力，而Go 2将更受其社区的影响。
目前在Go 2的提案中，大约有120个未解决的问题被标记为Go 2的提案，每一个问题都与重要的库或语言更改相关，而这些问题通常不能满足当前Go 1的兼容性。开发人员将这些提案分类为Go2Cleanup、NeedsDecision等，以便后续的执行操作。
在Go语言的生态中，拥有数以万计的程序员和代码，因此，所有的决策和改变必须谨慎，以免对稳定的生态造成破裂。因此，Go团队认为，需要实施新的提案评估流程。
提案评估流程的目的是收集对少数选定提案的反馈意见，以便作出最终决定。该过程或多或少与发布周期并行进行，包括以下步骤：
1、提案选择。Go团队选择了少量似乎值得考虑接受、但有做出最终决定的Go 2提案。
2、提案反馈。 Go团队发出一份罗列选中提案的公告。 该公告向社群解释了推进所选提案的初步意图，并收集了每个提案的反馈意见。 这使社区可以有机会提出建议、表达想法。
3、实施。 根据这些反馈，提案得以实施。 这些重要的语言和库更改的目标是在即将到来的发布周期的第一天提交它们。
4、实施反馈。 在开发周期中，Go团队和社区有机会尝试新功能并收集进一步的反馈。
5、启动决策。在三个月的开发周期结束时，根据在发布周期中收集的经验和反馈，Go团队最终会决定是否发布每个更改。一旦发布，这些被发布的提案就成为语言和库的一部分。未被发布的提案可能会重新起草，也可能会被永久拒绝。
通过两轮的反馈过程，可以起到一个筛选的作用，防止“功能蔓延”，有助于保持语言的简洁性。
一项提案至少满足以下条件：
1、解决大多数用户都觉得重要的问题；
2、不会对其他用户产生造成太大的影响；
3、提供一个清晰易懂的方案。
条件1确保了团队所做的任何更改都能帮助尽可能多的Go开发人员（使他们的代码更鲁棒，更容易编写等等）。条件2确保了团队的更改对少部分用户所带来的不便降到最低。
若是不满足条件3，提案将不会被实施。即便提案能够解决一个通用性的问题，思路很好，在没有实施方案的情况下，也会被拒绝，该提案需要重新起草。
团队认为此次推出的更新很好，应该能够高效地为用户服务，但更重要的是，这只是一个起点。在使用过程中，仍发现有时无法正常工作情况，团队将根据需要进行进一步优化。但关键是，在实际使用之前，并不知道如何改进。
一种保险的做法是使用少量向后兼容的语言。团队已经有很长一段时间没有进行语言上的修改。此外，做出这些变化无需担心破坏现有代码，因此可以作为一种完美的试验方式。
尽管如此，团队为Go 1.13版本下（此为提案评估过程中的第1步）选择Go 2用户提出以下意见：
1.＃20706 基于Unicode TR31的通用Unicode标识符：解决了使用非西文字母表的Go程序员的一个重要问题，并且对其他人都应该没什么影响。我们需要解决归一化问题，社区中反馈意见也很重要，但在此之后，实施路径获得了充分理解。请注意，标识符导出规则不会受到此变动的影响。
2.＃19308，＃28493二进制整形文字和对数字文字的支持：这些变化相对较小，在许多程序员中似乎非常受欢迎。这些问题可能还没有达到“重要问题”的程度（到目前为止，16进制数字运行良好）但是这一改动使得Go与大多数其他编程语言实现统一，并且解决了一些程序员的痛点。如果你并不在意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的兼容性），还是放弃这些功能（评估流程的最后一步）。
（因为在冻结期内很可能需要删除某个功能，所以新的实现必须做到禁用新功能后，也不会破坏系统其他部分的稳定性。对于语言的更改而言，这可能意味着所有与功能相关的代码都以“内部标记”加以保护。）
这将是Go团队第一次实施这一流程，因此冻结期也将是反思这一流程，并在必要时进行调整的好时机。
敬请期待！
原文：https://blog.golang.org/go2-here-we-come
