原文：blog.golang.org/go2-next-st…
现状
不出意外的话，我们将会在2019年8月发布Go 1.13版本。这是第一次对Go语言进行很实在的改变（而不是规范性的微调），这些改变很早以前就提出来，但是一直拖延着。
为了实现语言的改变，我们遵照“Go 2, here we come!” 文档中的评估流程，先从 Go 2 proposals （Go 2提案列表） 中挑选了一小部分可行的提案。
我们希望我们最初挑选的提案相对较小，并且几乎没有争议，以便于更大可能性去完成这些变更。这些“变更”的提案必须向后兼容才能最小化对模块的破坏性，这些模块允许指定Go语言版本，而不是默认构建方式。简而言之，作为第一轮的变革，主要还是为了迭代积累经验，而不是为了解决重大问题。
在原始提案列表中进行了修剪和扩展的提案：
通用Unicode标识符general Unicode identifiers 二进制整数文字binary integer literals 数字文本的分隔符separators for number literals 有符号整数移位计数signed integer shift counts 由于我们没有及时制定“一般的Unicode标识符”这个提案的具体的设计文档，因此我们没有对它进行修整。“二进制整数文字”的提案得到了显着扩展，并对Go的数字文本语法进行了全面的改革和现代化。我们在错误检查中添加了Go 2草案设计方案，该提案已被部分接受。
经过Go 1.13的这些初步变化之后，现在是时候期待Go 1.14，并确定我们接下来要解决哪些问题。
Go 1.14的相关提案
不忘初心，Go语言目前的目标与2007年相同：使软件开发规模化。然而“包版本管理”、“错误处理机制”和“泛型”这三大问题阻碍了Go语言的发展。
随着Go module的支持越来越强大，我们解决了包及包版本的管理，于是三大问题中就剩下了“错误处理”和“泛型”。
我们一直在努力解决这两个问题，并在去年的丹佛GopherCon上展示了草图设计 draft designs，并一直迭代。
在错误处理方面，我们发布了一个具体的、经过重大修改和简化的提案（下文中会提到）。
在泛型方面，我们还在努力中。在今年的圣地亚哥GopherCon上发表了一篇与之相关的谈话 (“Generics in Go” by Ian Lance Taylor) coming up 但是我们还没有具体的相关提案。
我们也希望能继续完成一些小改进。针对Go1.14版本，我们挑选了以下一些提案：
#32437. 内建的错误处理函数, “try” (design doc).
这是一个改进错误处理机制的具体提议。这个提议向后兼容性很弱，但是我们希望通过这个提议能够大大改善错误处理的方式。这个提议已经吸引了大量的意见反馈，因此不太容易跟进。我们建议从初始评论initial comment 开始，以便于快速了解概述，然后再阅读详细的设计文档。这个初始评论initial comment 包括几个链接，这几个链接是迄今为止的反馈的摘要。如果你想提交反馈，在提交之前，请遵守反馈建议（请参阅下面的“后续步骤”部分）
#6977. 允许嵌套接口 (design doc).
允许嵌套接口是一个老提案，并且是一个向后兼容的提案。
#32479 go vet中诊断 string(int) 转换.
在Go语言早期，为了方便引入了 string(int) 转换，然而这种方式很容易让新手混淆（string(10) 转换后是"\n"，而不是"10"）并且这种转换方式在当今unicode/utf8包可用的情况下不合理。然而，删除这种转换会导致不向后兼容，因此我们提议先使用vet 诊断错误。
#32466 采用加密原则 (design doc).
这是对我们希望采用的加密库的一组设计原则的反馈。另请参阅crypto/tls中关于删除SSLv3 支持的提议.
后续步骤
我们正在积极征求关于这些提案的反馈意见。我们特别想了解的是基于事实的证据，请在反馈中说明为什么提案可能在实践中不能很好地运作，或者我们可能在设计中遗漏的问题。
如果支持提案，列举出令人信服的例子也非常有用。
另一方面，请不要发布仅包含针对个人因素的问题：我们可以理解，但我们无法以任何建设性的方式解决。
在发布反馈之前，请花点时间认真阅读详细的设计文档和之前的别人提出的反馈或反馈摘要。特别是这些提案在经过了长期讨论后，您的关注的问题可能已在早期的评论中提出并进行了讨论。
不出意外，我们计划在Go 1.14版本中（2019年8月初）开始实施所有这些提案，以便在实践中对它们进行评估（实践是检验一切的真理）。根据提案评估流程，最终决定将在开发周期结束时（2019年11月初）完成。
感谢您帮助Go成为更好的语言！
