Go 语言的下一步 ： Russ Cox 谈 Go 2 规划

Posted 2021-04-05 开发资讯

7 月 13 日，Russ Cox 在 GopherCon 上分享了《The Future of Go》，回顾了 Go 语言的发展历史，展望了 Go 2。

Rob Pike、Robert Griesemer 和 Ken Thompson 就一门新的编程语言讨论了一段时间，在 2007 年 9 月 25 日，Rob 建议将其命名为 Go。

之后，Russ Cox 和 Lance Taylor 也加入了 Go 语言的设计团队。他们 5 人一起开发了两款编译器和一个标准库，为 2009 年 11 月 10 日 Go 语言以开源方式发布打下了基础。

接下来的两年，在开源社区的帮助之下，Go 语言引入了很多大大小小的变化。几乎每周都有一些不兼容的变化，用 Go 开发的程序也需要不断更新。这妨碍了 Go 语言进一步采用。这也促使开发团队重点考虑了 Go 1 的兼容性保证。

2012 年 3 月 28 日，Go 1 正式发布。

 

在 Go 1 发布之后，开发团队更看重的不再是改变语言，而是在自己的项目中使用 Go，不断改进实现。他们将 Go 移植到很多新的系统上，几乎重写了所有对性能比较敏感的地方，让 Go 运行更为高效，还开发了很多重要工具（如 race detector）。

从 Go 1 发布到现在，开发团队已经有了 5 年使用 Go 构建大规模、产品级系统的经验，现在是时候考虑 Go 的下一步演进与成长了。

Go 2 提上日程。

Russ 希望在社区的帮助下共同实现 Go 2。

目标

---

Go 今天的目标和十年前并无二致：Scale（规模化）。

让程序员更高效地管理两类规模化问题：一个是产品的规模化，特别是要与很多服务器交互的并发系统，比如云软件；一个是开发的规模化，特别是由大量松散协作的工程师共同编写的大规模代码库，比如现代的开源软件。

Go 2 的目标就是解决 Go 1 在规模化方面做的还不好的地方。

约束

---

目前已经有大量的 Go 语言开发者，有大量的 Go 代码，广泛的应用，都是对 Go 的约束。

据 Russ 估算，目前全世界的 Go 开发者至少有 50 万（估算方式见：https://research.swtch.com/gophercount）。

Go 2 必须考虑这些开发者。只有回报非常巨大时，才能让他们放弃旧习惯，学习新用法。

Go 2 必须接受现有的 Go 1 源代码。开发团队不希望割裂 Go 生态系统。（Python 社区的前车之鉴 ）在相当长的过渡期内，Go 2 导入 Go 1 的包，或者 Go 1 导入 Go 2 的包，应该能比较容易做到，这需要一些自动化的工具。

为将破坏控制在最小，每一个变化都要深思熟虑，而这又会限制能够引入多少变化。或许能做两三个，但是不能超过五个。

Russ 也简单提到了一些可能的变化：

I'm focusing today on possible major changes, such as additional support for error handling, or introducing immutable or read-only values, or adding some form of generics, or other important topics not yet suggested. We can do only a few of those major changes. We will have to choose carefully.

其中提到了大家讨论最多的泛型。

过程

---

Russ 介绍了 Go 的开发过程。

在尚未开源之前，设计团队的几个人办公室挨着，聚到一起聊一聊，白板上画一画，回头把讨论的内容实现就好了。有问题再回来讨论。

但是在社区化的今天，之前那种模式已经行不通了。

他总结现在的模式如下。

一是使用 Go，积累经验。

二是发现可能需要解决的问题，并清楚地表达出来，向其他人解释，最后写下来。

三是为问题提供解决方案，和他人探讨，并基于讨论改进方案。

四是实现该方案，评估，基于评估改进。

最后，交付该方案，将其添加到语言、类库或者开发者日常使用的工具中。

循环往复，不断迭代。

Go 2 会如何交付

---

如果把 Go 2 要增加的特性分为兼容部分和不兼容部分，Russ 提到的思路如下。

（1）先按照 Go 1 的版本发布计划，增量式交付兼容的部分，一个特性一个特性地加进来。这样有几个优势：

• 保持 Go 1 按正常节奏发布，及时修复 bug ，带来用户要依赖的改进。

• 避免将开发力量分散到 Go 1 和 Go 2 上。

• 避免 Go 1 和 Go 2 的分歧，简化迁移。

• 集中精力，每次交付一个变化，保证质量。

• 鼓励团队设计向后兼容的特性。

（2）再考虑不兼容部分。

一旦完成了所有向后兼容的工作，比如说是 Go 1.20 版本，就可以在此基础上开发 Go 2.0 的不兼容部分了。如果最终发现没有这样的变化，或许会直接将 Go 1.20 命名为 Go 2.0（想必熟悉 Java 的朋友对这样的策略并不陌生，Java 1.5 =》 Java 5）。不管怎样，届时开发工作都会从 Go 1.X 发布序列走向 Go 2.X 序列。

看到 Russ 举例的版本号—— 1.20，心里一紧，现在正在开发的版本是 1.9 ，9 到 20，掰着手指头数不过来啊。

Go 2 的具体计划，后面还需要开发团队和社区大量讨论，让我们共同期待吧。

对了，Go 2 的读法，也让程序员段子手们很兴奋。 

---

参考资料：

1.Toward Go 2  https://blog.golang.org/toward-go2

2. The Future of Go https://about.sourcegraph.com/go/the-future-of-go