Golang Go语言 1.18 泛型会来，但官方库支持可能得等等
Golang Go语言 1.18 泛型会来，但官方库支持可能得等等
Rob Pike: don’t change the libraries in 1.18
大意是担心一次改得太大出错了找补不回来（ Go 1 得全系列保证兼容，也不希望出现 Python 2/3 的那样的分裂情况），想先看看社区怎么用，再慢慢更新标准库。
标准库的实验会在老地方 golang/x/exp 里展开。
更多关于Golang Go语言 1.18 泛型会来，但官方库支持可能得等等的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
Go 语言之父 Rob Pike 昨日发 issue：我建议我们不在 Go 1.18 的标准库中使用泛型 - https:///github.com/golang/go/issues/48918 作者的理由很简单，Go 泛型是 Go 诞生以来最大的一次语言变化，Go 1.18 版本承载了太多的 change，容易出错。并且 Go 核心开发团队也没有使用新泛型的经验，他建议 Go 核心开发团队应该多等待、观察和学习。 我是十分赞同 Rob Pike 的建议的，不要把步子迈得太大。go 应该按照自己的节奏稳步前进。
具体可以看这个 git repo，引入进来增加了不少复杂度，go 的泛型的兼容性以及复杂性都会是比较大的问题：github.com/damonchen/go-generic-tutorial
不得不说一句，国内跟着微软走的程序猿，都想对它吐口吐沫吧。别说进微软，不是每个人都能进微软的。想到当年学.net 学 WP 学 XNA，每次想起来就非常的生气，浪费我好几年时间。不把开发者当人。想吃饭就别跟着微软混，随时砸你饭碗
#18 这个确实是，我都没有了解到，不过我印象里在 vgo 出来之前 /v2 就已经有人在用了，因为当时也没有其他方案来管理版本，而且这个设计是真的不敢恭维，我不止一次因为 v1 v2 的问题踩了坑，大多数情况下依旧还是弊大于利的
可能 /v2, /v3 这种设计单拎出来看起来没有必要（仅仅为了区分 lib 的向后兼容性和多版本引入，对比其它语言的包管理方案），但它确实是 Go mod 整体设计方案的一部分，类似的还有 Minimal Version Selection 这部分的设计也和其他包管理不同，后边 Russ Cox 还上升到了软件工程的角度来思考包管理的问题。他有一个视频演讲介绍得更清楚一些，如有兴趣可以参考。
应该有不少人不知道 import “github.com/dimfeld/httptreemux” 和 import “github.com/dimfeld/httptreemux/v5” 的区别。只能说和常用的 npm 太不同了
#22 go 包版本管理吃瓜的问题不是 go mod 不好，是因为他窃取了社区胜利的果实。
Russ Cox: 对于在 Go 1.11 里的 Go Module 的实现方式我感到非常兴奋。我上次瞅了一下最流行的大约 1000 个项目，93%的能够直接转换为 Go Module 。
Twitter 发出来之后，Sam Boyer(dep 的主要开发者)，转推了一条(后面不放英文原文截图了，可以到文章后面的连接去看):
Sam Boyer: 最初的(旧项目到 Go Module 的)转换从来不是问题，问题是从不拿工资的贡献者们那里偷走工作成果。
我上周 GoSF 的演讲是关于这个的。现在视频找不到了，不过我截了个图。
Russ Cox 回复了这条推:
Russ Cox: 我听了你的演讲。虽然我们谈了很长时间，但是明显你现在对于这一切，对于我还是感觉很受挫败，很沮丧。对此我真的很抱歉，我知道那是什么感受。
Sam Boyer: 你能这样说我很感激。你肯定也很不容易，对于这件事造成的过分的压力我也很抱歉。
但是这并不是你我之间的事情，我之所以在演讲中提到你，是因为你是后来社区文化和机制争论的源头。
另一个 Go 社区的重要贡献者，Peter Bourgon 说:
Peter Bourgon: 因为私下认识事件中的一些人，我承认我是有偏向的。不过作为一个外人看到这个事故现场，我可能以后对 Rust 兴趣更多一些了。为什么 Go 团队领导层总是拒绝从其他现代语言(的做法)中学习呢?
Russ Cox: Go 并不是要满足所有人的所有需求。如果你喜欢 Rust 的方式，就去用 Rust 吧。我也欣赏 Rust，事实上我花了很多时间研究 Rust，Swift 中的好的地方，但是适合一个语言的未必适合其他语言。
Peter Bourgon: 是的。但是我想不到原因为什么 go 的依赖管理没有从其他的依赖管理中学习到任何东西。我从局外人的角度来看，Go 歇斯底里的尝试不去达成任何其他人已经达成的共识，我不明白为什么要这样做。并不仅仅是你的问题。我参与了 dep 开始之前的讨论，在之前还一直在关注 glide 。我不知道为什么 go 的依赖管理社区就是不从其他(包管理)已经遇到的问题中学习。作为一个已经在提供开箱即用的工具方面证明了自己的语言和社区，我非常困惑为什么这么关键的一个部分(指包管理)几乎是刻意的设计得这么挫。
好吧，Peter Bourgon 其实有点歪楼了。
Russ Cox:我们是一个小团队，还有其他优先的事情要做。确实我们在这个领域晚了几年，但是事情正在往好的方面发展，几年之后再来看看我们做成什么样子。
Matt Farina(Glide 作者)跳出来了
你说你们是一个小团队，是因为你们把 Go 当做 Google 下面团队的一个产品，Google 这个团队是小的。如果你们创建一个社区，借助其他人的力量，那就是一个很大的团队。比如 Rust 的依赖管理团队就有不是 Mozilla 的人。
围攻之下 Russ Cox 开启了疯狂发推模式，连发 N 条 Twitter 阐述前因后果。
Russ Cox:
非常有道理的批评。我们并没有处理好依赖管理的社区进程。Go 的核心团队没有今早和足够的参与这个进程，没有能够引导平滑的落地。作为 Go 的技术负责人，这是我的责任，我为此道歉。
没太懂，意思是社区方案（ dep/glide ）足够好了，也赢得了社区，然后 go mod 靠官方强势推行打败了社区方案吗？
这个论断的前提是 go mod 没有社区方案优秀？
#31
起初官方不做，社区出了一大堆解决方案，著名的有 godep 、glide 。
然后有了一个“官方”的解决方案：dep 。
但是一年半以后，又出了个真正的官方解决方案：go mod 。
#31
简单的总结一下
Russ：我有管理责任，我道歉。dep 一开始就不是作为官方实现，是个实验，你们想多了。我想要 sementic import versioning，dep 不支持，所以没法把 dep 集成到 go 中。现在我搞了 go module Proposal 和原型实现(vgo)，大家都说好。
dep 的开发者：
当 dep 委员会成立的时候，我竭尽所能的，让它以及它推进的工作，尽可能的可靠和无懈可击，以保护工作组的信用，工作组成员的声誉，以及产出的产品的有效性。为了代替自核心团队的指导，甚至基本的交流，我们决定：
- 从社区的领袖和专家中征集成员
- 成立一个次级的顾问组支持所有相关的项目
- 花费了半年时间收集用户反馈和进行领域内的研究
- 详细 Review 了所有其他有意义的包管理工具
- 步调一致的进行设计，目标在所有的主要决策上达成一致
- 所有的一切，都煞费苦心的，公开的记录文档
我们做了所有的这一切，因为我们想要成为社区能够更近一步，解决一直被核心团队忽视的问题的典范。我无法找到比我们比我们所做过的事情更好的事情了。但是结果，这些努力就像我们从来没有做过任何事一样：核心团队最终不参与进我们所贡献的成果上面，而是坚持自己完成，本质上一个全新的重头开始的项目。
我想 dep/vgo 的结局很好的说明了，虽然 Go 领导层很乐意接受对 issue 和无争议的 Proposal 这样的贡献，但仍然在与大规模的自主自治的贡献者斗争。权利掌握在 Google 的核心开发团队里。
如果有一天我做关于这个最终失败的项目的演讲，我要在最后放一页幻灯片，上面有一个图，一艘船在岛上失事了，船长说: “你生命的意义就在于警告其他人”。我希望这个故事给别人一个警告：“如果你有兴趣对 Go 做出大的实质性的贡献，独立的勤奋工作不能补偿你那不是来自核心团队的设计”。
----
Addendum(作者看完在 Reddit 上的讨论添加的)：
这次引发的讨论启发了我。我想我对于发生的事情，有了更好的全景的视角。我认为 dep 团队和核心团队各自有完全不同的对对话的理解，直到 vgo 文章的出现让量子态塌缩了。
Dep 团队相信 dep 和之前出现的工具是不一样的，是一个经过研究和详细考虑，社区驱动的最终 go 依赖管理解决方案。核心团队认为 dep 和之前的工具本质上是同一类，是他们设计的最终的方案的前奏的一部分。
我相信 dep 团队很清楚他们的地位，能够从核心团队的表述中能够看出来是处于什么样的地位的。但是明显(dep 团队成员)没有能够普遍的理解这个地位，直到为时已晚，直到已经太晚。唉，事后来看是很显然的事情，但是当时谁又能够看得透呢?
Go 其实有点像 Google 的其他若干技术，比如 Bazel 、Kubernetes 、清教徒风格的 C++ style guide （还有很多一下想不起来了），也许很适合 Google 内部的一些场景，但在其他方面可能就会让人难受。
那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 php 吗？虽然没有泛型但写起来不复杂，也不比其他任何语言差，还可以全端一把梭，不香吗？人生苦短，我选 php 。
那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 kotlin 吗？虽然编译缓慢 gradle 更慢，但抱着 JVM 大腿生态问题不大，想尝鲜还有 coroutine，这东西某种意义上做的比 go 的 goroutine 好。更何况空安全啊等等各种漂亮的语法极大降低脑细胞阵亡概率。
go 在 dep 问题上处理确实欠妥，不过我喜欢的就是 go 跟 ios 似的，加东西瞻前顾后，先提供少量精华特性，再慢慢往上加，反观 某 js，除了糟粕就没多少精华了
世界范围内并不少，比 go 高 3-4 倍左右，是 java 的 1/2 左右，可以参见 jetbrains 的调查数据
如果一个语言三方库太少，他都活不到 2021 年，C#不缺少任何库，无非就是多少的问题，例如 java 的 json 解析库有 5-6 个，C#可能有 1-2 个
C 渣渣就算了吧，除了没有 GC 性能可能好一点点。写的慢，编译慢；浪费青春，浪费生命。
编码 5 分钟，修 core 2 小时（如果顺利的话）。项目大一点，编译时间巨长。
写得快，编译慢。编译慢倒是事实，得特别小心头文件嵌套……
但是写得慢，恕我直言，我怎么没这种感觉？ C++ 写起来很爽的，特别是算法，没有模板和零开销抽象写个锤子的算法？另外只要不含界面的东西，C++ 写起来也都挺好用的，只要你花点时间写个比如 1 万行的基础库屯着。
预言：如果 golang 加入泛型，那么 golang 的工程能力（团队生产力）会被削弱。
如果要增强一个语言（例如 java ）的工程能力（团队生产力），那么请在框架部分启用全部特性，然后在除框架以外的部分禁止团队成员使用泛型、继承等特性。
针对帖子“Golang Go语言 1.18 泛型会来，但官方库支持可能得等等”，作为IT领域Go语言方面的专家，以下是我的回复：
Go 1.18版本确实引入了泛型这一重要特性，这是Go语言自发布以来最重要的变化之一。泛型通过类型参数和类型约束，提高了代码的复用性和简洁性，使得开发者能够编写更通用的代码。
然而，关于官方库对泛型的支持，确实可能需要一些时间。在Go 1.18版本发布初期，一些核心工具和库可能还未完全适配泛型。Go核心团队正在与第三方工具的作者沟通，试图确保他们得到适当的更新，但各工具都有自己的时间安排表。
此外，值得注意的是，尽管Go 1.18已经支持泛型，但在生产环境中使用时仍需谨慎。开发者需要仔细测试代码，确保泛型的使用不会引入新的bug或性能问题。
总的来说，Go 1.18的泛型特性为Go语言带来了更强的灵活性和表达能力。随着时间和经验的积累，我们期待看到更多官方库和工具对泛型的支持，以及更多开发者利用泛型编写出更优秀的代码。
