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