Golang 泛型他来了！

天天喊要来了，倒是发布啊

最快不是明年八月

期待很久了

1.5 要等到 8 月份发布 2 不知道何年何月了

扫了一样，这还没来（发布）啊，只是更新了一下这个问题的进展。

天天喊要来了 /吃瓜

讨厌泛型 /Doge

interface 它不香吗（手动狗头）

够二啥时候出

我记得 go 最初的设计 不是不考虑泛型吗

非常期待

Hmmmm, Go 的官方 blog 也挂了 “Black Lives Matter”

赶紧出，马上学

预计最早得明年 8 月了。
The earliest that generics could be added to Go would be the Go 1.17 release, scheduled for August 2021

那以后 struct 的带多返回值方法要是用泛型是不是就四对括号了…

狼来了

可想清楚了，一旦引入泛型，那么 interface{}还有 [大道至简] 可就没了

@gramyang 不要这么打脸啊.

@nimdanoob 官方肛不住了,哈哈

和 C# 的泛型有啥区别？

请问下各位大佬,官方的这个例子中:
(s []T)是字符串切片参数,那前面的(type T)是什么意思呢 是对 s 的类型声明吗?
求解答

泛型还是有必要的，没有泛型有时候真的很麻烦

@iscraft #21 看看这个帖子
t/676318

明天起源 2，后天大行动，大后天 GTA6

这个新的提议还是有进步的，比之前的更加融洽

是这种吗 () () () () .....

表示难受

泛型怎么定义可比较呢？有点好奇

"The design is fully backward compatible with Go 1" Go team 太疯狂了，Go 2 遥遥无期哈。

.NET Core 发来贺电。

有了泛型和简化的错误处理 golang 就基本上可以广泛使用了，但这样缝合还保持向后兼容，一致性和“哲学”都没了。

一些标准容器用泛型支持就行了，再多就烦了，有泛型如果还是动态派发其实没啥意思，不过要是能 hkt，还是不错的

@timothyye 英国感觉有点像文革时候一样，到处雕像被毁坏，能改变什么呢。。。

Go Interface 实现不需要声明，真受不了，碰瓷式的一不留神说不定实现了某接口。。。

比起泛型，还是更期待能原生支持 10 进制小数。

Go Interface 实在别人费解，interface{}是个任人打扮的 XX 。

没有泛型真的很难简洁的实现类似 py 或 rs 那种复杂迭代器，希望尽早问世

还有有了泛型，起码标准库里好些函数方法不用提前实现一大堆接口了，比如堆的实现，每次用得实现 5 个方法，甚至不如直接手撕二叉堆，性能也不如手撕。

interface{}不香吗

「大道至简」的老一辈基本都快退休了

不是很明白 泛型和简洁有什么关系 有了泛型 就不简洁了吗
没了泛型 排序代码要写多少种

Go 团队真的很稳，很耐心挑选方案。

而且他们的思路也很正确，尽量把复杂性留在 “写” 泛型那边，而在 “用” 泛型那边则尽可能简化，这个设计原则非常棒。

比如，官方的例子 Print 函数使用了泛型，它是这样使用的：

Print([]string{"Hello, ", "world"}) //输出 Hello, world
Print([]int{3, 4, 5}) //输出 345

如果不管 Print 是怎么实现的，只看它是怎么使用的，就会觉得非常简洁，而且兼容 Go 1 。

有基本能用的泛型对于底层库第三方库都是好事，只是希望不要大幅增加编译时间就行

很多人已经开始玩了 https://www.reddit.com/r/golang/comments/haaz5w/the_next_step_for_generics_the_go_blog/

想要泛型，不如来先一起做 betterGo： https://github.com/PioneerIncubator/betterGo

不得不说，不用尖括号<>的泛型真的丑啊……虽然再丑的东西用习惯就好，但（）（）（）（）（）（）要是 ide 不给不同括号不同颜色我真的眼睛会花……

@PiersSoCool 生成器还是能解决大部分泛型场景. 如 https://github.com/a8m/syncmap

Yellow Lives Matter

@joesonw 生成器不好做- -，可以看看我上面的项目。

狼来了这么多次了，也没看见一次啊 （ doge

不知道是不是习惯了 Cpp 的写法，这样写`func Print(type T)(s []T)`我觉得很丑

@cmdOptionKana 又开始尬吹了，敢问主流泛型那个不是这样？

@rockyou12 这个应该会的

@cmdOptionKana

> 而且他们的思路也很正确，尽量把复杂性留在 “写” 泛型那边，而在 “用” 泛型那边则尽可能简化

用这边怎么设计都会很简化。关键看能不能把 “写” 泛型也给简化了，否则不是一个好设计。

@rockyou12 为什么大家都这么追求使用尖括号呢，为什么不想着如何把自定义泛型和内置泛型的语法统一起来呢？

@liulaomo 因为接收器泛型的时候可以有 4 个括号。

@fengjianxinghun 对，我也看着一大堆()不爽，但是何必非得使用<>这种异物呢？和内置泛型统一起来不香吗？

看起来是为了兼容之前的语法，希望不要成为第二个 try proposal 。

恭喜 golang 终于要入类型系统的门了

reddit 各种代码都出来了 反观 v 站，这就是程序员论坛吗

最早都要明年 8 月

@ica10888 编译兼容？但是语法完全不兼容。自定义泛型和内置泛型的语法完全是两套。

@whoami9894 习惯了 C++ 的写法觉得其他的都丑，然而所有年轻的语言都觉得 C++ 的写法反人类…虽然我一直是 C++ 吹，但是我知道大部分的人都认为 C++ 的语法很反人类，比如说 lambda…

别造成 py2 和 py3 级别的分裂就谢天谢地了

interface 坑的一逼, 装箱拆箱跟玩魔术一样, 泛型快到碗里来

好的 等出来我再转 go hhh

@tianshilei1992 别偷换概念，这里「习惯了 C++ 的写法」特指 C++ 采用的这种尖括号泛型语法，你把 C++ 换成 Java 、Rust 、TypeScript 也一样成立。而年轻语言觉得「 C++ 的写法反人类」指的是 C++ 的其他特性，显然这些被批判的部分并不一定包括泛型语法。

这个 go2go 工具转换出来的代码是什么样子的…

func Map(type T, M)(f func(T) M, s []T) []M {
result := make([]M, len(s))
for k, v := range s {
result[k] = f(v)
}
return result
}

func main() {
Print(Map(func(a int64) string { return strconv.FormatInt(a, 16) }, []int64{42, 100, 200}))
}


还可以，处理数据总算能写的简洁点了

go2 快来了，怕是又有一波降级

恭喜，程序可读性将会一去不复返

interface 又不是不能用（狗头）

@rockyou12 <>是病，得治。
这种 angle bracket 的习惯来自数学符号，正宗写法是 chevron （ ），只是在只有基本字符集支持的语言中才复用了大于小于号（<>）。结果词法歧义上就炸了……（看看 C++ >>。）
没看到歧义还觉得不丑，说明基本的实用审美已经被整得退化了。
技术上这种东西还真不如 () 加 tag，因为用 () 在文法歧义之前已经直接承认语义上的潜在歧义，因此正常的设计中会更积极地消歧义（如通过另外加关键字）。
无条件混用 <> 仍然是垫底的弟弟设计。

我最早看到 golang 2.0 说要支持泛型还是在 8102 年

@cmdOptionKana 下意识觉得你在黑 Go，再读一遍又觉得不对

该有的你还得有 doge

func Print(type T)(s []T) (int, string){
return 0, ""
}

这括号也太多了吧

@FrankHB 你说这些有啥用 lisp 、Haskell 美不美?搬砖好不好用？

@lithbitren 你可以看看 container/list

@notamail list 还好吧，而且队列手写也好写啊，直接用数组性能比 list 快几倍，我说的是 container/heap

当初夸 go 不加泛型和官方秉承简洁不多加功能的人会不会回去改掉他们的文章

泛型是 golang 最大的痛点（没有之一）。

golang 其他为人诟病的地方（比如错误处理，比如黑魔法太少），大约可归类为习惯问题，if err != nil 只是写法不一样，习惯之后，也足够用了，何况 goland 对于未处理的错误会标黄提示。

但是没有泛型这个实在不能忍，不仅代码丑陋，而且缺少类型提示与编译期错误检查（如果使用 interface{}、反射来曲线救国），运行时性能损失倒无所谓，绝大多数 golang 项目性能绝非瓶颈。

golang 官方从一开始就说没有泛型只是不好实现（怕拖慢编译速度），而不是彻底不考虑未来加入泛型的可能。

根据[golang 官方的开发者调查]( https://blog.golang.org/survey2019-results):

> Among the 25% of respondents who said Go lacks language features they need, 79% pointed to generics as a critical missing feature

对于语言特性缺失的调查，其中 79%都指向缺少泛型

看各个群里和论坛的评论，对 Go2 都是褒贬不一。
我想说的是，这是别人的语言，不可能 100%符合自己的口味，美帝不卡你脖子已经够意思了。

如果真不爽，就直接操刀 ast 搞一个自己的定制语言。
gofmt 和 golint 检查也是基于 ast 做分析。
基于 ast 可以扩展出新的语法来，比如七牛面向数据科学语言的 Go+语言。

可以简单看看这本书：《 Go 语法树入门开启自制编程语言和编译器之旅！》（ github 地址：chai2010/go-ast-book ）,
其实也就是把 ast 包里的代码简单讲讲。

当然为了写这个书，我们也定制了一个凹语言：目前已经是一个可以嵌入 Go 语言的脚本语言，
也是基于 Go 语言的 ast 定制，在语言的基本功能完成之后我们会公开代码。

@FrankHB 对嘛，你也说了，反人类的不是 <> 语法本身，而是 C++ 为了使用 <> 而多出来的问题。像 Java 、TypeScript 等语言也用 <> 语法表示泛型，但它并没有 C++ 这些反人类的问题。