Golang Go语言泛型他来了
Golang Go语言泛型他来了
https://blog.golang.org/generics-next-step
官方发布了几份草案，其中 go2 的泛型可以前往 https://go2goplay.golang.org 体验
更多关于Golang Go语言泛型他来了的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
预计最早得明年 8 月了。
The earliest that generics could be added to Go would be the Go 1.17 release, scheduled for August 2021
“The design is fully backward compatible with Go 1” —— Go team 太疯狂了，Go 2 遥遥无期哈。
Go 团队真的很稳，很耐心挑选方案。
而且他们的思路也很正确，尽量把复杂性留在 “写” 泛型那边，而在 “用” 泛型那边则尽可能简化，这个设计原则非常棒。
比如，官方的例子 Print 函数使用了泛型，它是这样使用的：
Print([]string{"Hello, ", “world”}) //输出 Hello, world
Print([]int{3, 4, 5}) //输出 345
如果不管 Print 是怎么实现的，只看它是怎么使用的，就会觉得非常简洁，而且兼容 Go 1 。
习惯了 C++ 的写法觉得其他的都丑，然而所有年轻的语言都觉得 C++ 的写法反人类…😂虽然我一直是 C++ 吹，但是我知道大部分的人都认为 C++ 的语法很反人类，比如说 lambda…
别偷换概念，这里「习惯了 C++ 的写法」特指 C++ 采用的这种尖括号泛型语法，你把 C++ 换成 Java 、Rust 、TypeScript 也一样成立。而年轻语言觉得「 C++ 的写法反人类」指的是 C++ 的其他特性，显然这些被批判的部分并不一定包括泛型语法。
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}))
}
还可以，处理数据总算能写的简洁点了
<>是病，得治。
这种 angle bracket 的习惯来自数学符号，正宗写法是 chevron （ ⟨ ⟩ ），只是在只有基本字符集支持的语言中才复用了大于小于号（<>）。结果词法歧义上就炸了……（看看 C++ >>。）
没看到歧义还觉得不丑，说明基本的实用审美已经被整得退化了。
技术上这种东西还真不如 () 加 tag，因为用 () 在文法歧义之前已经直接承认语义上的潜在歧义，因此正常的设计中会更积极地消歧义（如通过另外加关键字）。
无条件混用 <> 仍然是垫底的弟弟设计。
C++ 反人类的设计显然包括不知所谓的本该避免的文法歧义，使用 <> 多出来的问题就是 C++ 反人类设计的典型杰出代表之一，这不因为其它问题更拉仇恨而改变。你没有一下子搞清楚这点，而强调“并不一定”，看来是不够熟悉 C++ 。（事实是，不想硬抄 instantiation phase 而老实写形式语法的根本没法在实用上绕过这坨○。）
虽然其它许多用 <> 的语言并没有那么夸张的歧义问题，但是用 <> 的必要性仍然相当莫名其妙，有不尊重语用来源之嫌。
选择照抄 C++ 这样设计的语言设计者和语言的用户，大概也不一定了解 C++ 在这方面的历史包袱。而选择不照抄 C++ 却同样使用这种糟粕设计的语言设计者，大概至少一样无可救药（至少没几个语言有当初 C++ 对 basic source character set 那么纠结的需求，也不是事后才扩展出 template 的）。
泛型是 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 定制，在语言的基本功能完成之后我们会公开代码。
对嘛，你也说了，反人类的不是 <> 语法本身，而是 C++ 为了使用 <> 而多出来的问题。像 Java 、TypeScript 等语言也用 <> 语法表示泛型，但它并没有 C++ 这些反人类的问题。
Golang（Go语言）中的泛型确实是一个值得探讨的重要特性。尽管Go语言在设计之初并未原生支持泛型，但随着版本的更新，泛型功能已经得到了实现和增强。
泛型允许开发者编写适用于所有类型的模板代码，只有在具体使用时才会确定其真正的类型。这一特性极大地提高了代码的复用性和灵活性。通过泛型，开发者可以避免编写大量类型重复但逻辑相同的代码，从而简化开发过程，减少出错的可能性。
在Go语言中，泛型的使用非常广泛。它可以应用于函数、结构体、接口以及通道等多种编程元素。例如，你可以编写一个泛型函数来处理不同类型的切片或映射，而无需为每种类型单独编写函数。同样，你也可以定义泛型结构体或接口，以便它们能够处理多种类型的数据。
当然，泛型的使用也需要遵循一定的规则和约束。例如，类型参数需要满足一定的约束条件（如可比较性、可哈希性等），以确保代码的正确性和安全性。
总的来说，Go语言的泛型功能为开发者提供了更强大的工具来编写高效、可维护的代码。随着Go语言生态的不断发展和完善，泛型的应用场景也将越来越广泛。
