共计 1519 个字符，预计需要花费 4 分钟才能阅读完成。
大家好，我是煎鱼。
前两天 Go1.18 beta1 曾经公布，间隔正式公布 Go1.18 的生产可用还有 2 个月，也就是泛型行将正式面世。
最近正在收集泛型的一些材料，看到在 2015 年有人在 Hacker News 上的《Go 1.5 max procs default》吐槽 Go 不反对泛型是“政治”起因 …
看了还是有些意义的，与当初的矛盾点基本一致，为此分享给大家。
网友吐槽
网友 @aikah 认为 Go 团队不太可能在语言中退出泛型，这显然是一个政治问题而不是技术问题。错误处理也是如此。
和许多人一样，该网友 认为 Go 在极简主义和性能之间没有获得正确的均衡。拥护泛型的人赞成用编译时类型查看（总是平安的）换取运行时类型断言（可能失败）。
他们回绝抵赖这一事实。这就是他们拥护泛型的论点，并将最终侵害语言的任何潜在增长。他们基本上是在违反本人的利益。
官网回复
Russ Cox 做了正式的回复：很道歉，但不是：泛型是一个技术问题，不是一个政治问题。
Go 团队并 不拥护泛型自身，只是拥护做那些没有被很好了解或不能很好地与 Go 配合的事件。
这就是外围观点和矛盾点，也从 2009 年，连续到了当初。
会遇到的问题
Go 团队认为要将泛型的概念融入 Go，并与零碎的其余局部很好地配合，必须解决一些深层次的技术问题，而咱们并没有解决这些问题的方法。
对于这些问题，在几年前就在博客上写过一篇《The Generic Dilemma》：
即便克服了那一页上的问题，也有其余问题，接下来你会遇到的问题是：”如何让程序员以一种有用的、易于解释的形式省略类型正文“。
也就是如何更兽性、更易于的表白泛型的类型参数。
泛型例子
举个例子，C++ 容许你写 make_pair(1, "foo")，而不是 make_pair<int, string>(1, "foo")。
为了达到这种成果，推断正文背地的逻辑须要几页几页的标准，这并不是一个特地容易了解的编程模型，当事件出错时，编译器也不能轻易解释。
在这之后必定还有更多的新问题在这外面。
和专家沟通
Go 团队和一些真正的 Java 泛型专家谈过，他们每个人都说了大致相同的话：要十分小心，它不像看起来那么容易，而且你会被你犯的所有谬误困住。
作为一个 Java 示范，能够浏览一下《Java Generics FAQs – Frequently Asked Questions》的大部分内容：
看看过了多久你会开始思考 “ 这真的是最好的办法吗？”。
在泛型过程中会遇到许多问题，像是《How do I decrypt Enum<E extends Enum<E>>》：
为此，Go 团队在泛型的推动上十分审慎。
抵赖毛病
Go 团队说得很分明，抵赖这个事实：没有泛型是有肯定的毛病的。
你要么应用 interface{} 而放弃编译时查看，要么写代码生成器而使你的构建过程复杂化。
现有语言中实现的泛型也有明确的毛病，而且明天不斗争有一个十分大的益处：它使今天 采纳更好的解决方案变得更加容易。
总结
明天给大家分享了过来在国外社区针对 Go 泛型的各种争议和探讨，其实泛型的外围观点很明确：”Go 团队不拥护泛型自身“。
始终没能把泛型做起来，也是因为顾虑很多，做泛型要和 Go 多个局部，要解决很多深层次的问题，还要解决类型参数可读性等问题。所以始终拖到了当初。
回到行将 2022 年的当初，都预言对了。社区都在扯做泛型后的多个关联组件，以及泛型可读性和构造 …
显然，泛型就是双刃剑？你怎么看。
若有任何疑难欢送评论区反馈和交换，最好的关系是相互成就 ，各位的 点赞 就是煎鱼创作的最大能源，感激反对。
文章继续更新，能够微信搜【脑子进煎鱼了】浏览，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言能够看 Go 学习地图和路线，欢送 Star 催更。
