Go 负责人说以后不会有 Go2 了-51CTO.COM

大家好，我是煎鱼。

最近 Go 核心团队负责人 @Russ Cox（下称：rsc）专门写了一篇文章《Backward Compatibility, Go 1.21, and Go 2[1]》为 Go 这门编程语言的 Go1 兼容性增强和 Go2 的情况说明做诠释和宣传。

今天希望能够帮助你获悉 Go 未来的规划、方向以及 rsc 的思考。

Go1 破坏兼容性的往事

第一个案例，比较经典。在 Go1 的时候，这段代码是可以正常运行的。如下演示代码：

package main

import "net"

var myAddr = &net.TCPAddr{
    net.IPv4(18, 26, 4, 9),
    80,
}

但在 Go1.1，这段代码就跑不起来。必须要改成如下代码：

var myAddr = &net.TCPAddr{
    IP:   net.IPv4(18, 26, 4, 9),
    Port: 80,
}

因为在当时的新版本中，对 net.TCPAddr 新增了 Zone 字段。原先的未声明值对应字段的方式就会出现一些问题。

后续在新版本的规范中，官方直接对标准库提交的代码增加了要求，赋值时必须声明字段名。以此避免该问题的产生。

第二个案例，Go1.6 时，官方修改了 Sort 的排序实现，使得运行速度提高了 10% 左右。以下是演示代码，将根据名称长度对颜色列表进行排序并输出结果：

colors := strings.Fields(
    `black white red orange yellow green blue indigo violet`)
sort.Sort(ByLen(colors))
fmt.Println(colors)

一切听起来是那么的美好。

真实世界是改变排序算法通常会改变相等元素的排序方式。导致了 Go1.5 和 Go1.6 所输出的结果不一致：

Go 1.5:  [red blue green white black yellow orange indigo violet]
Go 1.6:  [red blue white green black orange yellow indigo violet]

按照顺序排序后，结果集的差异点在于：

如果说程序依赖了结果集的输出顺序，这将是一个影响不小的兼容性破坏。

第三个案例，类似的还有在 Go1.8 中，官方改进了 compress/flate 的算法，达到了在 CPU 和 Memory 没有什么明显变化下，压缩后的结果集更小了。听起来是个很好的成果。

但实际上自己内部却翻车了，因为 Google 内部有一个需要可重现归档构建的项目，依赖了原有的算法。最后自己 fork 了一份来解决。

从上面的部分破坏兼容性示例来看，可以知道 Go 官方也不是刻意破坏的。但又存在必然要修改的各种原因和考量。

为此在 Go1.21 起，正式输出了 GODEBUG 的机制，相当于是开了个官方 “后门” 了。将其作为破坏性变更后的门把手。

允许设置 GODEBUG，来开关新功能特性。例如以下选项：

也会根据根据 go.mod 中的 Go 版本号来设置对应 GODEBUG，以提供版本所约定的 Go1 兼容性保障策略。

如果对这块感兴趣，可以查看《加大力度！Go 将会增强 Go1 向后兼容性》，有完整的增强兼容性的规范说明。

Go 官方（via @rsc）正式回答了之前画的饼，也就是什么时候可以看到 Go2 的规范推出，打破 Go1 程序？

答案是永远不会。从与过去决裂、不再编译旧程序的意义上来说，Go 2 永远不会出现。从 Go 在 2017 年开始对 Go 1 进行重大修订的意义上来说，Go 2 已经发生了。

简而言之，透露出来的意思是：硬要说的话，Go2 已经套壳 Go1 上市了。

在未来规划上，不会出现破坏 Go1 程序的 Go2。工作方向会往将加倍努力保证兼容性的基础上，开展新工作。

整体上 rsc 对破坏 Go1 兼容性做了很长时间规划的回溯和规划，释出了一大堆手段，例如：GODEBUG、go.mod 版本约束等。

从而引导了 Go2 直接可以借壳上的方向，也更好兑现了 Go1 兼容性保障的规范承诺。单从这方面来讲，还是非常的深思熟虑的。

也可能会有同学说，看 Go 现在这样，说不定下次就变了。这可能比较难，其实 rsc 才上任做团队负责人没几年，工作履历上和其他几位骨干大佬在 Google 已经有非常长年的在职经验了。

图片

我目测一时半会是不会变的了。

想变，得等 Go 核心团队这一班子换了才有可能了。阻力也会很多，因为社区人多，一般会比较注重规范。