Go 1.18 泛型会来，但官方库支持可能得等等

向后兼容是个大坑，目前官方库怎么去兼容并支持泛型都没有个合适的方案，感觉会跟 gomod 之前过渡一样产生一大堆 /v2 /v3 的后缀，写起来一大堆坑

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

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 C#吗？除了内存高点，其他不比 go 差啊，甚至更强啊。
（是的，在中国提微软的东西就是政治不正确）

欢迎来 C# 体验一下真泛型

@Rwing 咋就政治不正确了，科普下，我现在就使用的.net 开发，感觉比其他的舒服多了

@Rwing 嗨，不存在，每个语言都有优秀的地方。

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 C++ 吗？除了写起来复杂点，其他不比 go 差啊，甚至更强啊。

Go 核心团队性格比较谨慎、稳健，很不错。

@Rwing 不得不说一句，国内跟着微软走的程序猿，都想对它吐口吐沫吧。别说进微软，不是每个人都能进微软的。想到当年学.net 学 WP 学 XNA，每次想起来就非常的生气，浪费我好几年时间。不把开发者当人。想吃饭就别跟着微软混，随时砸你饭碗

@Mitt Go mod 的 /v2, /v3 是基于 semantic versioning 的主动设计好吧，被你说成了问题。

@Rwing 想当年我也是 C#入门的。。。现在为了恰饭，还是乖乖写 Go

@Rwing 后端用.NET 开源项目确实少啊，这是全世界不正确，跟中国没啥关系。微软自己的 DAPR 都用 Go 来写了

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 Haskell 吗？除了写起来复杂点，其他不比 go 差啊，甚至更强啊。

@kidlj #10 /v2 /v3 是在 go mod 出来之前 gopath 的应对方案，在我看来这是个历史遗留

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 lisp 吗？除了写起来复杂点，其他不比 go 差啊，甚至更强啊。

@Rwing 三方库太少，不能什么都自己撸吧

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 Rust 吗？除了编译时间长点，其他不比 go 差啊，甚至更强啊。

@Mitt 关于 Go mod 的设计，Russ Cox 到今天写了 11 篇长篇博客介绍，其中关于 Semantic Import Versioning 的解释见 https://research.swtch.com/vgo-import 。

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 brainfuck 吗？除了编译时间长点，其他不比 go 差啊，甚至更强啊。

@kidlj #18 这个确实是，我都没有了解到，不过我印象里在 vgo 出来之前 /v2 就已经有人在用了，因为当时也没有其他方案来管理版本，而且这个设计是真的不敢恭维，我不止一次因为 v1 v2 的问题踩了坑，大多数情况下依旧还是弊大于利的

@inhzus brainfuck 是开发时间长，不是编译时间长

@Mitt 可能 /v2, /v3 这种设计单拎出来看起来没有必要（仅仅为了区分 lib 的向后兼容性和多版本引入，对比其它语言的包管理方案），但它确实是 Go mod 整体设计方案的一部分，类似的还有 Minimal Version Selection 这部分的设计也和其他包管理不同，后边 Russ Cox 还上升到了软件工程的角度来思考包管理的问题。他有一个视频演讲介绍得更清楚一些，如有兴趣可以参考。&list=WL&index=1&t=31s

@kidlj 应该有不少人不知道 import "github.com/dimfeld/httptreemux" 和 import "github.com/dimfeld/httptreemux/v5" 的区别。只能说和常用的 npm 太不同了

如果要政治正确的话，我真心推荐 pualang，可以扩展你的格局，还有顶层设计思维，为你赋能从而破圈突围

为什么编程都要搞政治正确这种浪费时间的事，github 从 master 该成 main 就浪费了不少宝贵生命，它礼貌吗？它正确吗？

说句***的话，我 java 用 spring 全家桶一把梭不挺好么

帖子主题不是 go 泛型吗，为啥总是提 xxx 语言更强更好，不抬一下屁股痒是吧。

@kidlj #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 的技术负责人，这是我的责任，我为此道歉。

@surbomfla <贬低其他语言 ，抬高自己用的语言和 tooling> 提供了程序员日常 15%的所有乐趣

@matrix67 对吃瓜不感兴趣，很高兴 Go mod 赢了

@matrix67 没太懂，意思是社区方案（ dep/glide ）足够好了，也赢得了社区，然后 go mod 靠官方强势推行打败了社区方案吗？

这个论断的前提是 go mod 没有社区方案优秀？

等 C++20 支持携程后就转去写 C++

等就等呗，多蛋疼一段时间

@rrfeng #31
起初官方不做，社区出了一大堆解决方案，著名的有 godep 、glide 。
然后有了一个“官方”的解决方案：dep 。
但是一年半以后，又出了个真正的官方解决方案：go mod 。

谨慎点好，别太激进成了第二个 python

@rrfeng #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 团队成员)没有能够普遍的理解这个地位，直到为时已晚，直到已经太晚。唉，事后来看是很显然的事情，但是当时谁又能够看得透呢?

@matrix67
@runze
感谢

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 js 吗？写起来不复杂，也不比其他任何语言差，还可以全端一把梭，不香吗？人生苦短，我选 js 。

@lvdb 那应该推荐 ts，还有 deno 引擎可以用

Go 其实有点像 Google 的其他若干技术，比如 Bazel 、Kubernetes 、清教徒风格的 C++ style guide （还有很多一下想不起来了），也许很适合 Google 内部的一些场景，但在其他方面可能就会让人难受。

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 php 吗？虽然没有泛型但写起来不复杂，也不比其他任何语言差，还可以全端一把梭，不香吗？人生苦短，我选 php 。

那个啥，说句中国互联网圈子政治不正确的话，我能推荐一下 kotlin 吗？虽然编译缓慢 gradle 更慢，但抱着 JVM 大腿生态问题不大，想尝鲜还有 coroutine，这东西某种意义上做的比 go 的 goroutine 好。更何况空安全啊等等各种漂亮的语法极大降低脑细胞阵亡概率。

go 在 dep 问题上处理确实欠妥，不过我喜欢的就是 go 跟 ios 似的，加东西瞻前顾后，先提供少量精华特性，再慢慢往上加，反观 某 js，除了糟粕就没多少精华了

@janxin 当然此处的 js 指用了 ts 的 js 呀

@stevenhawking 你们拍 h 片并不可以全端啊，写个移动端 app ？

@lvdb 不过 php 的确写起来好快啊，改起来也快

@stevenhawking 弱类型语言要啥泛型？

@rahuahua 世界范围内并不少，比 go 高 3-4 倍左右，是 java 的 1/2 左右，可以参见 jetbrains 的调查数据
@tabris17 如果一个语言三方库太少，他都活不到 2021 年，C#不缺少任何库，无非就是多少的问题，例如 java 的 json 解析库有 5-6 个，C#可能有 1-2 个

@lvdb 不过一般我对其他语言用户都是推荐 CoffeeScript

相比 go 我真的喜欢 rust，但编译起来 实在比 go 慢太多，而且每次 target 目录太大了，

@ipwx C 渣渣就算了吧，除了没有 GC 性能可能好一点点。写的慢，编译慢；浪费青春，浪费生命。

编码 5 分钟，修 core 2 小时（如果顺利的话）。项目大一点，编译时间巨长。

@yx1989 写得快，编译慢。编译慢倒是事实，得特别小心头文件嵌套……

但是写得慢，恕我直言，我怎么没这种感觉？ C++ 写起来很爽的，特别是算法，没有模板和零开销抽象写个锤子的算法？另外只要不含界面的东西，C++ 写起来也都挺好用的，只要你花点时间写个比如 1 万行的基础库屯着。

影响不大，放到 exp 也是可用。
主要加了泛型，自己写库爽多了

都 2021 年了怎么还有一提 .NET 就微软的
.NET 早就开源给了 .NET 基金会
.NET 基金会是独立运作的组织

主题: xxx
回复: me me me

@yejinmo https://zhuanlan.zhihu.com/p/417524950

@Rwing C#主要是一开始绑定死了 windows,不支持 linux 呀,语法再好,不支持没有办法呀,不想 golang,一开始就是全平台

@Rwing 说的是开源基础项目，不是指业务，云原生基本就是 Go+Java 的市场了。做业务没必要有歧视，公司选择自然有自己的考虑，中国选择 Go 也没问题。

预言：如果 golang 加入泛型，那么 golang 的工程能力（团队生产力）会被削弱。
如果要增强一个语言（例如 java ）的工程能力（团队生产力），那么请在框架部分启用全部特性，然后在除框架以外的部分禁止团队成员使用泛型、继承等特性。

@chenqh 那是好多年前的事情了 C#早已跨平台

泛型真的这么有必要吗！？