| 导读 | 使用 Go 工程中的 go.mod 文件内的 go 版本号来控制编译的选择，决定各个库在不同 Go 版本下以不同的表现来应用其特性，将会影响编译时的决定。 |
大家好，我是煎鱼。
本周末在学习的时候，看到 Go 团队大当家 Russ Cox（下称：rsc）在近期分享的《GopherCon 2022: Russ Cox - Compatibility: How Go Programs Keep Working[1]》，讲的是 Go 在兼容性方面的现有问题和思考，还埋了个新预期。
如下图：
他提出了一个新的 Slogan：“Go is boring, and that's good.（Go 很无聊，这很好）”，原因在于无聊代表稳定的。无聊意味着你能够专注于你的工作，而不是我们的工作。
核心来讲，Go 团队希望 Go 足够简洁，Gopher 不要整天卷 Go 的各种奇思妙计，要把精力都关注到自己的工作上，不要关注他们。
我一开始听起来多少有点道理和自己的想法，听着听着这个车就刹不住了。
在最后的最后，rsc 冷不丁的正式官宣：不会有 Go2 了，会一直保持 Go1，将会加倍投入对 Go1 兼容性的建设，这将非常有价值。
如下图：
当然，他也讲了，狭义里的 Go2 可能已经发生了，只是慢慢转为了 Go1 的新特性融入到了 Go 之中。（我很想说，版本号也还是 Go1，好一个意识...）
最重要的，那些没法兼容的 “新” 东西怎么办？大方向的大招已经在前文《加大力度！Go 将会增强 Go1 向后兼容性》有介绍过。
核心之一：使用 Go 工程中的 go.mod 文件内的 go 版本号来控制编译的选择，决定各个库在不同 Go 版本下以不同的表现来应用其特性，将会影响编译时的决定。
如下图：
在上述说明中，主模块、模块 A、模块 B，分别根据 go.mod 内的 go 版本号，应用到了不同的可用特性（有的可以用泛型，有的不可以用带下划线的数字，有的都不能用等）。
这本质是结合 Go modules 原本的依赖管理逻辑，再复用 go.mod 的 go 版本号给不同版本的不同特性来做好编译的控制逻辑。
未来将不会有 Go2，都会是 Go1.x。
已经找到能往里各种塞的姿势了。
原文来自：
本文地址：//gulass.cn/no-more-go2.html编辑：清蒸github，审核员：逄增宝
Linux大全：
Linux系统大全：
