Golang 泛型他来了！

• 資深大佬 : yuchenyang1994

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

• 資深大佬 : fiypig

  最快不是明年八月

• 資深大佬 : mijimoji

  期待很久了

• 資深大佬 : keepeye

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

• 資深大佬 : echo1937

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

• 資深大佬 : lewinlan

  天天喊要来了 /吃瓜

• 資深大佬 : putaozhenhaochi

  讨厌泛型 /Doge

• 資深大佬 : boretothee

  interface 它不香吗（手动狗头）

• 資深大佬 : jon

  够二啥时候出

• 資深大佬 : nimdanoob

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

• 資深大佬 : iRiven

  非常期待

• 資深大佬 : timothyye

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

• 資深大佬 : lower

  赶紧出，马上学

• 資深大佬 : timothyye

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

• 資深大佬 : maoxs2

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

• 資深大佬 : syrupofplum

  狼来了

• 資深大佬 : gramyang

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

• 資深大佬 : imkerberos

  @gramyang 不要这么打脸啊.

• 資深大佬 : securityCoding

  @nimdanoob 官方肛不住了,哈哈

• 資深大佬 : Rwing

  和 C# 的泛型有啥区别？

• 資深大佬 : iscraft

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

• 資深大佬 : duanquanyong

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

• 資深大佬 : Vegetable

  @iscraft #21 看看这个帖子
  https://www.v2ex.com/t/676318

• 資深大佬 : winterbells

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

• 資深大佬 : dbskcnc

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

• 資深大佬 : araraloren

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

• 資深大佬 : vus520

  表示难受

• 資深大佬 : linghutf

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

• 資深大佬 : kidlj

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

• 資深大佬 : beyondex

  .NET Core 发来贺电。

• 資深大佬 : Jirajine

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

• 資深大佬 : ppphp

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

• 資深大佬 : hantsy

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

• 資深大佬 : hantsy

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

• 資深大佬 : Hellert

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

• 資深大佬 : hantsy

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

• 資深大佬 : lithbitren

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

• 資深大佬 : lithbitren

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

• 資深大佬 : wangyzj

  interface{}不香吗

• 資深大佬 : scnace

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

• 資深大佬 : PiersSoCool

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

• 資深大佬 : cmdOptionKana

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

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

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

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

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

• 資深大佬 : lxml

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

• 資深大佬 : Kisesy

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

• 資深大佬 : ChristopherWu

  想要泛型，不如来先一起做 betterGo： https://github.com/PioneerIncubator/betterGo
• 資深大佬 : rockyou12

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

• 資深大佬 : joesonw

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

• 資深大佬 : zjupigeon

  Yellow Lives Matter

• 資深大佬 : ChristopherWu

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

• 資深大佬 : AlohaTing

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

• 資深大佬 : whoami9894

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

• 資深大佬 : fengjianxinghun

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

• 資深大佬 : janxin

  @rockyou12 这个应该会的

• 資深大佬 : liulaomo

  @cmdOptionKana

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

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

• 資深大佬 : liulaomo

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

• 資深大佬 : fengjianxinghun

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

• 資深大佬 : liulaomo

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

• 資深大佬 : ica10888

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

• 資深大佬 : CosimoZi

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

• 資深大佬 : blless

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

• 資深大佬 : ThanksSirAlex

  最早都要明年 8 月

• 資深大佬 : liulaomo

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

• 資深大佬 : tianshilei1992

  @whoami9894 习惯了 C++ 的写法觉得其他的都丑，然而所有年轻的语言都觉得 C++ 的写法反人类…

• 資深大佬 : ConradG

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

• 資深大佬 : prenwang

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

• 資深大佬 : CoderGeek

  好的 等出来我再转 go hhh

• 資深大佬 : Balthild

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

• 資深大佬 : Trim21

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

• 資深大佬 : islxyqwe

  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}))
  }

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

• 資深大佬 : jmyz0455

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

• 資深大佬 : liberty1900

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

• 資深大佬 : asche910

  interface 又不是不能用（狗头）

• 資深大佬 : FrankHB

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

• 資深大佬 : FrankHB

  @Balthild C++ 反人类的设计显然包括不知所谓的本该避免的文法歧义，使用 <> 多出来的问题就是 C++ 反人类设计的典型杰出代表之一，这不因为其它问题更拉仇恨而改变。你没有一下子搞清楚这点，而强调“并不一定”，看来是不够熟悉 C++ 。（事实是，不想硬抄 instantiation phase 而老实写形式语法的根本没法在实用上绕过这坨○。）
  虽然其它许多用 <> 的语言并没有那么夸张的歧义问题，但是用 <> 的必要性仍然相当莫名其妙，有不尊重语用来源之嫌。
  选择照抄 C++ 这样设计的语言设计者和语言的用户，大概也不一定了解 C++ 在这方面的历史包袱。而选择不照抄 C++ 却同样使用这种糟粕设计的语言设计者，大概至少一样无可救药（至少没几个语言有当初 C++ 对 basic source character set 那么纠结的需求，也不是事后才扩展出 template 的）。

• 資深大佬 : Darain

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

• 資深大佬 : releaseme

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

• 資深大佬 : allenhu

  该有的你还得有 doge

• 資深大佬 : gravitybox

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

  这括号也太多了吧

• 資深大佬 : rockyou12

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

• 資深大佬 : notamail

  @lithbitren 你可以看看 container/list

• 資深大佬 : lithbitren

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

• 資深大佬 : hjahgdthab750

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

• 資深大佬 : einsdisp

  泛型是 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%都指向缺少泛型