go泛型的缺点
“劣势”：go是带垃圾回收的编程语言，因此不管go的stop the world的时间有多么短，延迟有多么小，依然属于这类语言，这就天然与c,cpp,rust间划清了界线。虽然go初衷是成为系统级编程语言，虽然go的性能可以满足99%的场合的需要，但不能否认的是在一些性能超级敏感的场合，选择go依然要慎重。go的另外一个“劣势”就是能玩的花样太少，崇尚一个事情只有一个或少数几种写法。这不符合某些开发人员炫技的心理需求。于是就被诟病为是资质平平的程序员才会去用的语言。go 1.18将加入泛型（类型参数），这算是
为什么 Go 语言没有泛型？
Go 语言没有泛型的原因有两个。第一个原因是泛型和其他特性一样不是只有好处，为编程语言加入泛型会遇到需要权衡的两难问题。语言的设计者需要在编程效率、编译速度和运行速度三者进行权衡和选择，编程语言要选择牺牲一个而保留另外两个。第二个原因是目前的多数泛型提案都有明显的缺陷，而且在 1.x 版本中，提升语言其他方面性能带来的收益比泛型带来的更多 。
驳狗屎文 "我为什么放弃Go语言
此篇文章流传甚广, 其实里面没啥干货， 而且里面很多观点是有问题的. 这个文章在 golang-china 很早就讨论过了.最近因为 Rust 1.0 和 1.1 的发布, 导致这个文章又出来毒害读者.所以写了这篇反驳文章, 指出其中的问题.有好几次，当我想起来的时候，总是会问自己：我为什么要放弃Go语言？这个决定是正确的吗？是明智和理性的吗？其实我一直在认真思考这个问题。开门见山地说，我当初放弃Go语言（golang），就是因为两个“不爽”：第一，对Go语言本身不爽；第二，对Go语言社区里的某些人不爽。毫无疑问，这是非常主观的结论。但是我有足够详实的客观的论据，用以支撑这个看似主观的结论。文末附有本文更新日志。确实是非常主观的结论, 因为里面有不少有问题的观点(用来忽悠Go小白还行).第0节：我的Go语言经历先说说我的经历吧，以避免被无缘无故地当作Go语言的低级黑。2009年底，Go语言（golang）第一个公开版本发布，笼罩着“Google公司制造”的光环，吸引了许多慕名而来的尝鲜者，我（Liigo）也身居其中，笼统的看了一些Go语言的资料，学习了基础的教程，因对其语法中的分号和花括号不满，很快就遗忘掉了，没拿它当一回事
go泛型什么时候出
go泛型2022年出。Golang团队认为在类型系统和运行时的复杂性花费太大，还没找到可以和这个复杂性相抵的良好设计。内置的map和slice其实都有泛型的味道，加上可以用interface{}来构造容器，可以达到泛型的效果。所以目前为止还没有直接的支持泛型。Java语言泛型：在Java SE 1.5之前，没有泛型的情况的下，通过对类型Object的引用来实现参数的“任意化”，“任意化”带来的缺点是要做显式的强制类型转换。而这种转换是要求开发者对实际参数类型可以预知的情况下进行的。对于强制类型转换错误的情况，编译器可能不提示错误，在运行的时候才出现异常，这是一个安全隐患。
重磅：Go 1.18将移除用于泛型的constraints包
背景Go官方团队在Go 1.18 Beta 1版本的标准库里引入了contraints包，以支持泛型设计。该包定义了Signed，Unsigned, Integer, Float, Complex和Ordered共6个interface类型，可以用于泛型里的类型约束(type constraint)。例如，使用constraints包可以编写如下泛型代码：函数min是一个泛型函数，接收2个参数，返回其中的较小者。类型参数T的类型约束contraints.Ordered的定义如下。该代码的执行结果为。对于不熟悉Go泛型和constraints包的同学，建议参考之前的教程了解。现状Go官方团队的技术负责人Russ Cox提议将constraints包从Go标准库里移除，放到x/exp项目下。Russ Cox给出的理由包括：仍然存在关于constraints包的疑问，虽然许多人对名称感到满意，但也有许多人不认可