导读 使用 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 版本下以不同的表现来应用其特性,将会影响编译时的决定。

如下图:

  • 主模块(main module):声明 go 版本是 1.19,他可以使用泛型和带下划线的数字。
  • 模块 A v1.0.0:声明 go 版本是 1.17,模块 A 里的包不可以使用泛型(1.18 才开始支持),带下划线的数字可以正常使用。
  • 模块 B v1.2.1:声明 go 版本是 1.12,两者都不能用。
  • 在上述说明中,主模块、模块 A、模块 B,分别根据 go.mod 内的 go 版本号,应用到了不同的可用特性(有的可以用泛型,有的不可以用带下划线的数字,有的都不能用等)。

    这本质是结合 Go modules 原本的依赖管理逻辑,再复用 go.mod 的 go 版本号给不同版本的不同特性来做好编译的控制逻辑。

    未来将不会有 Go2,都会是 Go1.x。

    已经找到能往里各种塞的姿势了。

    原文来自:https://www.51cto.com/article/745159.html

    本文地址:https://www.linuxprobe.com/no-more-go2.html编辑:清蒸github,审核员:逄增宝

    Linux命令大全:https://www.linuxcool.com/

    Linux系统大全:https://www.linuxdown.com/

    红帽认证RHCE考试心得:https://www.rhce.net/