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

标准库

泛型

don't

Rob

62 条回复 • 2021-10-28 18:56:47 +08:00

1

Mitt

2021-10-14 16:39:53 +08:00

2

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

2

matrix67

2021-10-14 17:19:18 +08:00

1

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

3

Rwing

2021-10-14 17:21:48 +08:00

18

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

4

Rwing

2021-10-14 17:22:20 +08:00

1

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

5

SpiritLingPub

2021-10-14 17:23:38 +08:00

1

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

6

nanmu42

OP

2021-10-14 17:25:18 +08:00

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

7

ipwx

2021-10-14 17:37:28 +08:00

9

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

8

cmdOptionKana

2021-10-14 17:42:20 +08:00

1

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

9

Glauben

2021-10-14 17:45:28 +08:00

6

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

10

kidlj

2021-10-14 17:47:37 +08:00 via iPhone

1

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

11

cyrivlclth

2021-10-14 17:48:31 +08:00

1

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

12

rahuahua

2021-10-14 17:48:46 +08:00

1

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

13

pisc

2021-10-14 17:50:21 +08:00

1

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

14

Mitt

2021-10-14 17:52:04 +08:00

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

15

kiotech

2021-10-14 17:53:41 +08:00

1

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

16

tabris17

2021-10-14 17:56:15 +08:00

1

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

17

xinhaiw

2021-10-14 18:00:33 +08:00

2

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

18

kidlj

2021-10-14 18:04:21 +08:00

2

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

19

inhzus

2021-10-14 18:16:20 +08:00 via iPhone

1

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

20

Mitt

2021-10-14 18:28:47 +08:00

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

21

windfarer

2021-10-14 18:34:01 +08:00

1

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

22

kidlj

2021-10-14 18:38:36 +08:00

1

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

&list=WL&index=1&t=31s

23

XTTX

2021-10-14 18:51:54 +08:00

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

24

xiaofan305

2021-10-14 18:52:22 +08:00 via iPhone

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

25

XTTX

2021-10-14 18:57:05 +08:00

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

26

chendy

2021-10-14 19:07:45 +08:00

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

27

surbomfla

2021-10-14 19:19:18 +08:00 via Android

6

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

28

matrix67

2021-10-14 19:24:00 +08:00

6

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

29

XTTX

2021-10-14 19:44:53 +08:00

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

30

kidlj

2021-10-14 19:52:46 +08:00 via iPhone

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

31

rrfeng

2021-10-14 20:59:52 +08:00

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

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

32

bug123

2021-10-14 21:13:51 +08:00

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

33

FrankAdler

2021-10-14 21:28:14 +08:00 via iPhone

1

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

34

runze

2021-10-14 21:44:33 +08:00

2

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

35

iyear

2021-10-14 22:00:11 +08:00

1

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

36

matrix67

2021-10-14 22:21:51 +08:00

8

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

37

rrfeng

2021-10-14 22:33:19 +08:00 via Android

@matrix67
@runze
感谢

38

mx8Y3o5w3M70LC4y

2021-10-14 22:51:39 +08:00 via Android

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

39

janxin

2021-10-14 23:21:24 +08:00 via iPhone

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

40

agagega

2021-10-14 23:48:47 +08:00 via iPhone

1

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

41

stevenhawking

2021-10-15 00:51:33 +08:00

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

42

iseki

2021-10-15 01:09:24 +08:00

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

43

lxml

2021-10-15 01:16:16 +08:00 via Android

1

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

44

mx8Y3o5w3M70LC4y

2021-10-15 09:00:55 +08:00 via Android

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

45

mx8Y3o5w3M70LC4y

2021-10-15 09:01:45 +08:00 via Android

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

46

mx8Y3o5w3M70LC4y

2021-10-15 09:03:07 +08:00 via Android

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

47

qq1340691923

2021-10-15 09:25:42 +08:00

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

48

Rwing

2021-10-15 10:05:55 +08:00

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

49

janxin

2021-10-15 10:10:28 +08:00

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