出泛型后 API 怎么办？Go 开发者要注意了
大家好，我是煎鱼。
前段时间社区里一下子就爆了，主要是各大媒体引用了 Go 语言之父 Rob Pike 所提的《go: don’t change the libraries in 1.18》。
很多社交媒体都做了跟进，认为 Rob Pike 是硬性的反对 Go 泛型的 API 改造！
如果读者只看了标题，有可能会产生一些误解实际上其表达的意思和近期 Go 社区讨论的事项是有关联的，要一起综合来看。
为此，今天煎鱼就和大家一起来理一理，看看 Go 泛型 API 的改造工程，是个怎么一回事？
现状
马上就是 2021.11 月，连深圳都变冷了…根据 Go 语言的发布周期，Go1.18 版本的发布，那就是 2022.02 月左右。
现在给到 Ian Lance Taylor、 Robert Griesemer 等大佬仅剩 3 个月的时间给大家讨论泛型细节，进一步完善实现，达到生产可用。
抛出 Go 泛型的实现进度不说，现在遇到了一个比较大的问题。那就是实现泛型后 ”如何更新泛型的 API“。
这之中包含好几个方面，分别是：既有标准库、开源库，新标准库等。不同库之间是不同的人在维护。
但这里存在一个大问题，如下图：
Russ Cox 在 9 月就提出了 ”how to update APIs for generics“ 的疑惑，当时显然这一块还没有共识。在 11 月的现在，从讨论的记录来看，怎么做还没有达成一个最终的明确共识（初步已有，未正式答复）。
但存在一个问题，Go 社区对于泛型的迫切度，热情非常高，各种泛型化的标准库的提案都提出来了，推着设计者往前走。
争议
结合来看 Rob Pike，更多是：建议和提醒 Go 社区和核心开发团队，要 ”悠着点“，Go1.18 想支持泛型，做完成库的改造，还得代价小，毕竟细节很多。
引用其理由，核心论据是：
- 在一个版本中，做泛型、标准库等，要做的事情太多，很可能会弄错。
- 没有在 Go 中使用新类型的经验，无法为其设计提供有力的依据。
- Go1 兼容性的承诺，在任何细节上出错的代价都很高，要等待、观察和学习。
和一句谚语很接近：”不要一口气吃胖子“，何况没有相关的经验，都只是详细的推理、预演，需要晋升。
在 Go issues 中也有人吐槽，1.18 空有泛型的实现。其他配套的标准库等都没有，那这个 Go1.18 出来的泛型意义是？
后续
虽然还没有最终拍板，但是根据讨论的过程和社区赞同数（👍）来看，如下：
后续仍然会设计、构建、测试和使用用于切片（Slice）、地图（Map）、通道（Channel）等的新库。
这些库并没有生产可用，会把他们放在 golang/x/exp 仓库中，可以使用，仅作为现阶段的实验性的库，没有兼容性保障。
该实验库会在一两个周期内会改变、调整和发展。能够让 Go 社区的开发者们尝试一下使用，以便接受更多的意见。
再根据使用者的反馈通过经验和分析进行更新，就会把它们移到主仓库中，才达到正式生产可用的级别。
总结
在今天这篇文章中，我们针对 Rob Pike 为什么会要调整 Go 泛型后的标准库 API 等的提议进行了分析。
为此我们了解到 Go 核心团队对 ”how to update APIs for generics“ 的顾虑，以及现有社区的激情，综合来看，给出的逐步演进的泛型方案建议。
以此可知，Go 完整泛型（含配套库）的生产可用，可能还要经历几个 Go 版本，让不少人望穿秋水了…
