@sarvatathagata 确实。
不过暂时没有找到其它满意的名称。
对同时使用此 linker 的同学，可以把 Gold 装成 godoge 将就着用: go get -u go101.org/gold/godoge
;D

@yzongyue +Android 25% ;D

@zpvip 多了 20 多页吧，< 5%页数。 ;D

@sagaxu google trend 显示所有语言的流行度都远超其它国家，不只 Golang? 那片文章没有意义

@askfilm 跑题了，;)

@sagaxu
> 中国之外也就一般。

Go 在美国比中国用的还多。公司有：cloudflare, uber, google, docker, lyft, digitalocean, HashiCorp, dropbox, circleci, keybase 等等, 详见: https://github.com/golang/go/wiki/GoUsers#united-states (此页也列出了很多其它国家的使用情况)
产品就更多了：k8s, docker, gvisor, lxd, kata-container, etcd, consul, terraform, istio, envoy, linkerd2, flannel, calico, wavenet, traefik, nat, tidb, cockroachdb, vitess, go-leveldb, boltdb, badgerdb, pebble, minio, ipfs, go-etherum 和 n 多其它区块链项目。

@PiersSoCool 要改? 还是要加？

@iPhoneXI 语法是不可能改的了。

不过话说 Go 和 Rust 在简洁度上各有长短。

@nicoljiang 噢，;D

几年前搭了一个本地个人 wiki，使用了一个开源的 php wiki 软件（目前已经不再维护了）。后来荒废了。最近准备把它重新运行起来，整理一下里面的内容。擦，老的开源的 php wiki 软件的代码竟然不能在最新的 php 上运行，n 多语法错误。服了，世界上最好的语言连兼容性都不支持。

虽然我非常抵触使用引用来描述一个值这种说法（因为常常引起误解），
这里为了和大家保持一致，暂时还是使用此说法。

当修改一个指针参数所指的值的时候，此指针可以被看做是一个引用值。
但是当此指针参数本身被修改的时候，此此指针应该被看做是一个非引用值。

简单说来，在一个函数内部对一个形参本身进行的任何修改都不会体现到相应传递的实参上。
因为此形参只不过是相应实参的一个副本。

@zyt19940914

> 使用信道需要考虑的一个重点是死锁。当 Go 协程给一个信道发送数据时，照理说会有其他 Go 协程来接收数据。如果没有的话，程序就会在运行时触发 panic，形成死锁。
> 同理，当有 Go 协程等着从一个信道接收数据时，我们期望其他的 Go 协程会向该信道写入数据，要不然程序就会触发 panic。

这个需要需要上下文情景理解。 不过无论如何，这么描述都是欠妥的。这两句话想强调的是当所有用户协程都同时阻塞时，程序将崩溃退出（非 panic ）。但这只是官方编译器的实现，白皮书对此并未做要求。

@1608637229
取子切片时，第二个下标可以大于基础切片的长度，但是不能大于基础切片的容量。具体见 @lilydjwg 列出的白皮书中的一段。

@reus Robert Griesmer 和 Ian Lance Taylor 俩人应该都没到 60，还算中年吧。；）
不过现在貌似 Russ Cox 的话语权最大。

@lxml 老头子们基本都退了，现在是年轻人操盘。Rob Pike 是相当抵触 type alias 的。

@Cbdy 加了范型不想用可以不用啊。但对于某些项目来说，范型很重要。目前 Go 主流项目扎堆于于网络和工具一个重要的原因就是缺少范型。范型可以帮助 Go 开拓新的疆土。

@reus 和 D 模板还真有店像。
https://en.wikibooks.org/wiki/A_Beginner%27s_Guide_to_D/Templates_and_Generic_Programming/Mixins

应该说兼有 C++（但 type/function 输出）和 D （多个输出）模板的特点。


@sorra 这老爷子准备把 C++设计成百科全书吗？作为一个只懂 C++98 的大叔，表示看不懂新世纪的 C++代码。

@reus 事实上，此提案更多地借鉴了 C++模板。C++模板不滥用的时候，其实可读性还是挺高的。

这下面有很多例子中使用了不带 function body 的 contracts。
https://github.com/dotaheor/unify-Go-builtin-and-custom-generics/tree/master/examples/src/go

个人感觉此提案相对官方草案有以下优点：
1. 和内置范型更接近。
2. 主题语法完全和 Go 1 兼容.
3. 相对于官方草案，少了很多新语法。

@reus
这个提案也可以不用 function body 来做约束的。