Go 语言设计失误，缺少远见？
发布时间：2021-10-20 13:28:13 所属栏目：语言 来源：互联网
导读：泛型 为什么 Go 语言这么久都没有泛型，是不是 Go 官方不够 聪明，抄作业都不会抄。这显然是不对的。 有如下几点原因： 泛型本质上并不是绝对的必需品。 泛型不是 Go 语言的早期目标。 其他 feature 更重要，把精力放在这些上面，Go 团队人力很有限的。 历史
|
泛型
为什么 Go 语言这么久都没有泛型，是不是 Go 官方不够 “聪明”，抄作业都不会抄。这显然是不对的。
有如下几点原因：
泛型本质上并不是绝对的必需品。
泛型不是 Go 语言的早期目标。
其他 feature 更重要，把精力放在这些上面，Go 团队人力很有限的。
历史尝试
在以往的尝试中，Go 团队有人进行过不少的泛型 proposal 试验。基本时间线(via @changkun)如下：
Type Functions 2010年 Ian Lance Taylor
Generalized Types 2011年 Ian Lance Taylor
Generalized Types v2 2013年 Ian Lance Taylor
Type Parameters 2013年 Ian Lance Taylor
go:generate 2014年 Rob Pike
First Class Types 2015年 Bryan C.Mills
Contracts 2018年 Ian Lance Taylor, Robert Griesemer
Contracts 2019年 Ian Lance Taylor, Robert Griesemer
Redundancy in Contracts(2019)'s Design 2019年 Ian Lance Taylor, Robert Griesemer
Constrained Type Parameters(2020, v1) 2020年 Ian Lance Taylor, Robert Griesemer
Constrained Type Parameters(2020, v2) 2020年 Ian Lance Taylor, Robert Griesemer
Constrained Type Parameters(2020, v3) 2020年 Ian Lance Taylor, Robert Griesemer
我们观察一下，10 年过去了，Ian Lance Taylor 依然在开展泛型提案，持续地在思考着 Go 泛型。
坚持思考，这一点值得我们学习。
下一步计划
在 2021 年尾巴的我们，明年(2022年) Go1.18 左右就可以见到 Go 泛型，基本跑不了。
在出来前可以看看《Go 1.17 支持泛型了?具体怎么用》，可以作为玩具用了。
接下来可以预见泛型出来后，一堆工具库和数据结构很大可能会被逐步改写，像是《Go 提案：增加泛型版 slices 和 maps 新包》，早已摩拳擦掌。
届时 Go 源码类别的书的部分内容也会失时效，需要关注 Go 版本的时效性。
错误处理
在日常工程中，我们写的、看到最多的可能就是这一段标志性 Go 代码：
func main() {
x, err := foo()
if err != nil {
// handle error
}
y, err := foo()
if err != nil {
// handle error
}
z, err := foo()
if err != nil {
// handle error
}
s, err := foo()
if err != nil {
// handle error
}
}
这是在业内被吐槽的最多的，甚至都可以用来作为 Gopher 的互认。
设计方向
那 Go 是瞎设计的吗，就粗制滥造，搞个错误 err 的返回约定惯例。像是：
func foo() err {
return nil
}
其实并不是，Go 团队在设计上有意识地选择了显式的设计方向，如下：
使用显式错误结果。
使用显式错误检查。
这和其他语言不一样 ，是由于 Go 团队也认识到了异常处理的不可见错误检查所带来的问题。
设计草案有一部分是受到了这些问题的启发。如下：
目前 Go 官方也没有打算去掉 “显式” 这一做法，新版 Go2 错误处理的核心目标是：“错误检查更加轻便，减少专门用于错误检查的 Go 程序代码的数量和所花费的时间。”。
从 Go2 的趋势来看，主要是增加关键字和修饰来解决这个问题，相当于是堆积木了，而不是直接把他干掉的。
这在 Go 核心团队内是非常明确的。
依赖管理
Go 语言在一开始是完全基于 GOPATH 作为依赖管理的模式，当时也闹了不少的争议出来。有以下核心问题：
依赖要手动拉取和下载，没有强版本化的概念，开发者很难受(例如：不兼容升级、要拉取同一份)。
依赖和工程代码必须在 GOPATH 下才能运行，不能任意摆放。
所以在 Go1.0~Go1.11 中，各路神仙发招，社区出现了各种诸如 dep、glide、godep 等依赖包管理工具。
（编辑：3v站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
