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

1,756 阅读5分钟
原文链接: mp.weixin.qq.com

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