回归现实：Go Leader 对 1.18 泛型的期望

大家好，我是煎鱼。

前段时间根据 Go 泛型的最新动态，我写了一篇《出泛型后 API 怎么办？Go 开发者要注意了》文章，引发了不少小伙伴的热议。

Go 核心开发团队的现任 Leader @Russ Cox 在 golang-dev 中正式发表《expectations for generics in Go 1.18》对 Go 泛型给出了 “期待”，可以认为是后续的计划了。

如果不出现严重的问题，Go 1.18 将会包括对泛型的支持，并且这次泛型的支持将会是有史以来最大的一次语言变化，对以下几点有顾虑：

• 最佳实践.
• 生产经验
• 兼容性承诺。

接下来，煎鱼带大家一起了解 Russ Cox 发表的 Go 泛型进程，知悉官方一手消息。

最佳实践

Go 团队表示不知道使用泛型的最佳实践是什么，所以给出的官方文档将无法就何时使用泛型和何时不使用泛型给出精确、明确的答案，只可以给出粗略的指导。

此处可以参考《Effective Go》的最初版本，是在不间断地写了一整年的 Go 代码后，才正式输出的。

按照现有的计划，官方只会提供关于如何使用泛型的文档，暂时无法提供任何关于风格、最佳实践的规定性文档。

在提供的标准库上，先是已经通过提案的 maps 和 slices库会先放到 golang.org/x/exp 中作为实验，不会保证向后兼容。待成熟后，再推广到标准库中。

可以明确，Go 泛型出来后，社区就会陆续开始百花齐放，接着有官方输出推荐方法了，历史是如此的相似。

生产经验

目前 Go 团队没有关于泛型的生产经验，因此会在文档中给出明确提示，让大家在生产中使用泛型的时候应该适当谨慎。

泛型出来后，会陆续涉及到大量的重写工作，但是由于现在处于中间阶段。正在重写的 Go 1.18 工具链去同时适配泛型、非泛型代码是需要时间和经验的，有一定的风险。

因此泛型出来后，可能会出现一些意想不到的问题，仅在生产发现（教训）。

兼容性承诺

Go1.18 会和其他 Go1.x 版本一样，保证向后兼容的承诺：不会破坏用 Go 1.18 构建的代码，包括使用泛型的代码。

如果是最坏的情况，如果发现 Go 1.18 的语义有一些致命的问题，并需要改变它们（例如：在Go 1.19 中）。

将会使用 go.mod 文件的 go 行来确定该模块中的源文件是期待 Go 1.18 还是 Go 1.19+ 语义，以此实现版本控制。但目前来看，不需要这样做。

也建议急于使用 Go 泛型的开源库作者，做好泛型和非泛型版本代表的支持和隔离，这样对用户会更加的友好。

总结

可以明确的是，Go 泛型的整体推进方案，在这篇文章中均已说明。Go 官方团队也与许多第三方工具的作者进行沟通。

第三方工具可能不会在 Go 1.18 发布时就完全支持泛型，这会由各作者自行根据自己的时间表来更新。

煎鱼猜测推进节奏就是：

1. 支持泛型语法。
2. 观察。
3. 推进标准/工具库。
4. 逐步替换。
5. 修 BUG。
6. 观察、优化
7. 生产可用。

大概需要 2~3 个 Go 版本，需要 1~2 年，Go 泛型的各类配套组件就会基本完善，可用，转为持续优化了。

你对 Go 官方的推进计划此怎么看呢，欢迎在评论区留言和交流！