标准库 | Tony Bai

十月 28, 2021

img{512x368}

本文永久链接 – https://tonybai.com/2021/10/28/expectations-for-generics-in-go-1.18

2021年10月中旬，Go语言之父Rob Pike在github上的Go项目中发了一条issue：建议不在Go 1.18的标准库中使用泛型。

不得不说“姜还是老的辣”！Rob Pike的理由很简单，Go泛型是Go诞生以来最大的一次语言变化，Go 1.18版本承载了太多的change，容易出错。并且Go核心开发团队也没有使用新泛型的经验，他建议Go核心开发团队应该多等待、观察和学习。我是十分赞同Rob Pike的建议的，不要把步子迈得太大。Go应该按照自己的节奏稳步前进。

Rob Pike的这个issue引发了Go核心团队与社区的热烈响应。离Go 1.18版本发布还有4个月左右的时间了，后续Go泛型到底如何落地，整个Go社区需要一个明确的方向。

今天，Go核心团队技术负责人Russ Cox在golang-dev group发文，针对Rob Pike的issue介绍了Go 1.18版本与泛型当前进展与后续的支持策略，这确定了Go核心团队与社区的努力方向。这里粗略翻译一下供大家参考。

如果没有意外的严重问题，Go 1.18版本将包含对泛型的支持。泛型是Go1发布以来最重要的变化，当然也是我们有史以来最大的一次语言变化。这封邮件粗略解释了泛型的加入对我们和用户的意义。

任何Go的新功能特性，无论是语言还是库，都带有不确定性，包括不确定如何使用它们，不确定如何不使用它们，以及不确定有哪些微小的bug已经通过了现有的测试集。泛型也不能避免这种不确定性；事实上，因为泛型是一个大型的新功能，所以它的不确定性也相应地更大。

因为我们不知道使用泛型的最佳实践是什么，所以我们的文档将无法就何时使用泛型和何时不使用泛型给出精确、明确的答案。即便我们仍然可以并将给出粗略的泛型使用指南。作为比较，我们是在不间断地写了一整年的Go代码后，才写出了Effective Go的最初版本的。我们在泛型方面同样还没有较高水平使用经验，所以我们当然会提供关于如何使用泛型的文档，但我们短期内不能提供任何关于泛型代码风格和最佳实践方面的指南性文档。很简单，因为我们也欠缺这方面的实践与经验。

因为我们不知道编写泛型包的最佳实践是什么，所以我们发布的最初的泛型代码–特别是通过提案程序的maps和slices包–将首先放在golang.org/x/exp中，那里不能保证向后兼容。一旦我们有了更多的经验，我们希望能将其中一些包推广到标准库中。唯一例外的是constraints包，它是编写某些泛型代码的基础，它将在Go 1.18中就被添加到标准库中。

因为我们没有任何关于泛型的生产经验，所以我们会在发布说明中明确指出，在生产中使用泛型的时候应该适当谨慎。这并不是对Go核心团队出色工作的批评。这只是一个观察，泛型与大多数Go的变化不同。当我们重写垃圾收集器或改变调用惯例时，我们会在测试和生产中使用新的实现来运行谷歌的所有Go程序，这样就能很好地验证变化，揪出难以发现的错误。相比之下，用正在进行中的Go 1.18工具链重建非泛型代码并不能验证对泛型的支持，这意味着我们无法建立同样的信心。

综上所述，Go 1.18与其他Go 1.x版本一样具有向后兼容的承诺：我们不会破坏用Go 1.18构建的代码，包括使用泛型的代码。在最坏的情况下，如果我们发现Go 1.18的语义有一些致命的问题，并需要改变它们（例如在Go 1.19中），我们将使用go.mod文件的go版本指示符来确定该module中的源文件是使用Go 1.18还是Go 1.19+的语义。(我们预计不需要这样做！)

我们预想到一些包的作者可能会急于采用泛型。如果您正在更新您的软件包以使用泛型，请考虑将新的泛型API隔离到自己的文件中，并为其使用Go 1.18的构建标签（//go:build go1.18），以便Go 1.17用户可以继续构建和使用非泛型部分。

同样值得注意的是，第三方工具可能不会在Go 1.18发布时完全支持泛型。我们正在与许多工具的作者交谈，并试图确保他们得到适当的更新，但各个工具都有自己的时间表。

我们收到的一个常见的问题是：考虑到所有这些不确定性，为什么不把泛型变成可选项加入Go 1.18？答案是，在这一点上，减少不确定性的唯一方法是让其默认可用。当我们在Go 1.5版本中让vendor机制作为可选项加入时，发生的情况是几乎没有人真正使用它，直到Go 1.6版本默认开启它。所以Go 1.5版本没有减少我们对Go开发者使用vendor情况的不确定性。另一方面，Go 1.5版本无疑将生态系统分为”在标准Go下运行的代码”和 “在启用vendoring后运行的代码”两个部分。我们希望在这里尽可能地避免这种结果。

这里每个人可以做的最重要的事情就是写一些泛型代码，如果你发现了bug，不清楚的编译器错误等等，请让我们知道。我最近写了一些泛型数据结构，对整体的体验非常满意。我希望你也会这样；如果没有，请提交bug。谢谢!

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强，欢迎大家加入！

img{512x368}

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展；短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite
“Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go 1.17中值得关注的几个变化

八月 17, 2021

0 条评论

本文永久链接 – https://tonybai.com/2021/08/17/some-changes-in-go-1-17

Go核心开发团队在去年GopherCon大会上给Go泛型的定调是在2022年2月份的Go 1.18版本中发布，那可是自Go诞生以来语法规范变动最大的一次，这让包括笔者在内的全世界的Gopher们都满怀期待。

不过别忘了，在Go 1.18这个“网红版本”发布前，还有一个“实力派”版本Go 1.17呢！美国当地时间2021年8月16日，Go 1.17版本在经过两个RC版本之后正式发布！并且值得庆幸的是Go 1.17版本并没有过多受到Go 1.18版本这个“网红”的影响，Go 1.17默默地加入和优化了着实不少的特性。在这一篇文章中，我们就来看看Go 1.17版本中有哪些值得关注的变化。

1. 语言特性变化

Go属于那种极简的语言，从诞生到现在语言自身特性变化很小，不会像其他主流语言那样走“你有的我也要有”的特性融合路线。因此新语言特性对于Gopher来说属于“稀缺品”，属于“供不应求”那类事物^_^。这也直接导致了每次Go新版本发布，我们都要首先看看语言特性是否有变更，每个新加入语言的特性都值得我们去投入更多关注，去深入研究。Go 1.17在语言特性层面做了两方面的小改动，下面我们来看看。

第一个是对语言类型转换规则的扩展，允许从切片到数组指针的转换，下面的代码在Go 1.17版本中是可以正常编译和运行的：

// github.com/bigwhite/experiments/tree/master/go1.17-examples/lang/slice2arrayptr/main.go
func slice2arrayptr() {
    var b = []int{11, 12, 13}
    var p = (*[3]int)(b)
    p[1] = p[1] + 10
    fmt.Printf("%v\n", b) // [11 22 13]
}

Go通过运行时对这类切片到数组指针的转换代码做检查，如果发现越界行为，就会通过运行时panic予以处理。Go运行时实施检查的一条原则就是“转换后的数组长度不能大于原切片的长度”，注意这里是切片的长度(len)，而不是切片的容量(cap)。

第二个变动则是unsafe包增加了两个函数：Add与Slice。使用这两个函数可以让开发人员更容易地写出符合unsafe包使用的安全规则的代码。这两个函数原型如下：

// $GOROOT/src/unsafe.go
func Add(ptr Pointer, len IntegerType) Pointe
func Slice(ptr *ArbitraryType, len IntegerType) []ArbitraryType

unsafe.Add允许更安全的指针运算，而unsafe.Slice允许更安全地将底层存储的指针转换为切片。

2. go module的变化

自Go 1.11版本引入go module以来，每个Go大版本发布时，go module都会有不少的积极变化，这是Go核心团队与社区就go module深入互动的结果。

Go 1.17中go module同样有几处显著变化，其中最最重要的一个变化就是pruned module graph（修剪的module依赖图）。Go 1.17之前的版本某个module的依赖图由该module的直接依赖以及所有间接依赖组成，无论某个间接依赖是否真正为原module的构建做出贡献，这样go命令在解决依赖时会读取每个依赖的go.mod，包括那些没有被真正使用到的module，这样形成的module依赖图被称为完整module依赖图（complete module graph）。

Go 1.17不再使用“完整module依赖图”，而是引入了pruned module graph（修剪的module依赖图）。修剪的module依赖图就是在完整module依赖图的基础上将那些“占着茅坑不拉屎”、对构建完全没有“贡献”的间接依赖module修剪后的依赖图。使用修剪后的module依赖图进行构建将有助于避免下载或阅读那些不必要的go.mod文件，这样Go命令可以不去获取那些不相关的依赖关系，从而在日常开发中节省时间。

但module依赖图修剪也带来了一个副作用，那就是go.mod文件size的变大。因为Go 1.17版本后，每次go mod tidy（当go.mod中的go版本为1.17时），go命令都会对main module的依赖做一次深度扫描(deepening scan)，并将main module的所有直接和间接依赖都记录在go.mod中（之前说的版本只记录直接依赖）。考虑到内容较多，go 1.17将直接依赖和间接依赖分别放在两个不同的require块儿中。

3. 编译器与运行时的变化

Go 1.17增加了对Windows上64位ARM架构的支持，让开发者可以在更多设备上原生运行Go。但这个版本编译器最大的变化是在amd64架构下率先实现了从基于堆栈的调用惯例到基于寄存器的调用惯例的切换。

并且，切换到基于寄存器的调用惯例后，一组有代表性的Go包和程序的基准测试显示，Go程序的运行性能提高了约5%，二进制文件大小典型减少约2%。也就是说你的Go源码使用Go 1.17版本重新编译一下就能获得大约5%的性能提升，真希望这样的优化越多越好！对更多平台的基于寄存器调用惯例的支持将在未来的版本中出现。

除了改为基于寄存器的调用惯例之外，Go 1.17编译器还支持包含闭包的函数的内联(inline)了！这样一来，一个带有闭包的函数可能会在函数被内联的每个地方产生一个不同的闭包代码指针，因此，
Go函数的值不能直接比较！

Go编译器还在Go 1.17中引入了//go:build形式的构建约束指示符，以替代原先易错的// +build形式。

4. 其他变化

保留龙芯架构GOARCH值

在Go 1.17版本中，Go编译器保留了中国龙芯cpu架构的GOARCH值 – loong64。关于龙心GOARCH值选用loong64还是loongarch64还有过一段激烈的争论，最终大多数都赞同的loong64取得了最后的胜利。

Go test变化

Go test引入-shuffle的洗牌标志位，用以控制单元测试或benchmark的执行顺序。

另外T和B两个类型分别都增加了Setenv方法用于在test和benchmark执行期间设置环境变量。

time包增加Time对象的GoString形式输出

我们使用%#v输出一个Time对象实例时，Go 1.17之前的版本输出内容如下面：

Go 1.16.5输出：

time.Time{wall:0xc03f08c0d06c9ed0, ext:83078, loc:(*time.Location)(0x11620e0)}

Go 1.17增加了GoString方法，该方法在Time对象以%#v格式输出时被自动调用，其输出结果如下：

time.Date(2021, time.August, 17, 20, 29, 42, 58245000, time.Local)

5. 小结

除上述变化之外，Go的其他标准库随着新版本的发布也都会有大量的小改动，但每个开发人员对标准库的关注点差别很大，因此，在这个系列中不会详细做说明了，大家还是参考Go 1.17的发布说明文档各取所需吧^_^。

与传统的“Go新版本值得关注的几个变化”系列有所不同，本期内容较为简单和概括，因为更多内容，我将在后续的Go 1.17新特性详解系列中针对上述值得关注的新特性做进一步说明。详解系列已经写好，不过首发在了本人运营的星球“Gopher部落”上了，如果你迫切想深入了解这些新特性，可以加入星球阅读。

本文所涉及的源码可以在这里 – https://github.com/bigwhite/experiments/tree/master/go1.17-examples/