大家好，我是程序员幽鬼。
早上看到 Go 创始人之一 Rob Pike 发了一个 issue：go: don't change the libraries in 1.18。有人发文说了这件事。然后立马看到有人问：Go1.18 没有泛型了？
首先要明确，Go1.17 就包含了泛型的核心代码，只是默认不启用，循序渐进。
那 Rob 这个 issue 是什么意思？不贴原文了，说一下大概意思。
Go1.18 版本，因为泛型的引入，会是该语言自创建以来变化最大的一次。语言层面支持泛型，但不少功能需要库的支持。这有两个层面的问题：
- 已有库如何更好的支持泛型；
- 增加新库让泛型更好用；
这两方面，之前都有相关 issue 讨论，比如：proposal: bytes: add Grow, Clip; maybe add bytes/strings Insert, Delete、增加 slices 和 maps 包等。
这些是迟早要做的事情。不过 Rob Pike 认为，如果这些事情都在 Go1.18 做，一下子加入太多东西，难免会有问题，甚至可能是库的设计问题。引入新的库，大家没有任何使用经验，设计是否合理？但 Go 一直保证兼容性，如果处理不好，因为兼容性，处理起来会很费劲。
因此，Rob 建议，应该先将新库放入 golang/x/exp 下面（之前就存在这个 exp），方便大家进行使用、体验、测试，然后反馈，Go Team 可以根据大家的反馈，进行调整。一旦经过一段时间的检验，更多人认可了，再合入主仓库。
从该 issue 下面的评论看出，大家对这个决定还是很支持的。泛型来得晚，是因为 Go 官方很谨慎，一直在努力寻找更好的方案。现在终于要来了，也不能操之过急，最后阶段得稳住，平滑过渡。临门一脚得踢稳当。
应该基本确定，Go 1.18 发布时，标准库不会有过大的变化。
有疑问加站长微信联系（非本文作者）
golang连最基础的slice都一堆坑，加上泛型以后就是赶鸭子上架，最后变成cpp的stl那样不论不类的东西 你要认真去搞stl 最后项目一堆坑，你得小心翼翼地拿个小本本记着哪些地方有坑要避开，(因为stl的代码你改不了) 只能远远躲着，不去搞stl自己封装组件，你连面试都过不了，土憋老板和hr已经习惯了复制粘贴jd,反正不管有用没用，会拼与不会拼的单词都要写上，别的公司这么要求，我也这么要求 反正会得越多越好
泛型不支持的话, go会在占据最重磅业务的应用市场上被逐渐淘汰, 因为泛型真的太重要了. 不太明白你说的slice的坑是什么, 正常使用的话应该不会那么容易遇到坑的吧. 非要搞那些奇技淫巧炫富就不好说了.
golang 就不是设计用来做业务应用的， 仔细阅读 https://studygolang.com/articles/12907 里面说的
就象游泳的看着刘翔拿金牌，就觉得我现在缺双跑鞋，实际穿上跑鞋游泳淘汰得更快。 加上泛型只是把interface{}的写法改成any更短的单词，让码农刷题的时候少打几个字，根本改变不了golang本身的缺陷， 不加泛型至少码农还可以debug
*value.(*interface{})加了泛型码农只会对着满屏的报错一脸蒙逼。只管挖坑不管填坑的golang让码农跳进一个５米深的坑，本来吭吃坑吃挣扎几下，还能爬出来，结果加了泛型从５米深的坑掉进一个１０米深的坑，再也爬不出来了泛型，我倒是用的不多，无所谓加不加，倒是错误 处理，赶紧弄下