大家好，我是炸鱼。Go1.18beta1已经在两天前发布了，距离正式发布Go1.18forproduction还有2个月的时间，也就是说泛型即将正式发布。最近在搜集一些关于泛型的资料。看到2015年有人在HackerNews上抱怨说Go不支持泛型是因为“政治”原因……还是有一定道理的，和现在的观点矛盾的基本一致，分享给大家。网友吐槽网友@aikah认为Go团队不太可能在语言中加入泛型。这显然是一个政治问题而不是技术问题。错误处理也是如此。与许多人一样，这位网友认为Go并没有在极简主义和功能性之间取得适当的平衡。泛型的反对者赞成用编译时类型检查（这总是安全的）来换取运行时类型断言（这可能会失败）。他们拒绝承认这个事实。这是他们反对泛型的论点，最终会损害该语言的任何潜在增长。他们基本上是在违背自己的利益。官方回复RussCox做出了官方回复：抱歉，但不是：泛型是一个技术问题，而不是政治问题。Go团队本身并不反对泛型，只是反对做一些不太容易理解或不太适合Go的事情。这是核心观点和矛盾，从2009年一直延续到现在。将遇到的问题Go团队认为，为了将泛型的概念集成到Go中并与系统的其余部分很好地配合，必须解决一些深层次的技术问题，而我们没有解决这些问题的方案.几年前我在博客上写过这些问题《The Generic Dilemma》：即使你克服了那个页面上的问题，还有其他问题，你将遇到的下一个问题是：“如何让程序员使用一种有用的、可解释的方式来省略类型注解”。也就是如何更人性化、更轻松地表达泛型类型参数。泛型示例例如，C++允许您编写make_pair(1,"foo")而不是make_pair(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年的现在，一切都是对的。社区在谈论泛型之后的多个关联组件，以及泛型的可读性和结构……显然，泛型是一把双刃剑？你怎么认为。如有任何问题，欢迎在评论区反馈交流。最好的关系是相互成就。您的好评是创作炸鱼最大的动力。感谢您的支持。文章持续更新中。可以微信搜索【脑补炸鱼】阅读。本文已收录在GitHubgithub.com/eddycjy/blog中。学习Go语言可以看Go学习地图和路线。欢迎星星提醒。
