如何看待go語言泛型的最新設計？
用圓括弧 + type關鍵字來做type abstraction好嗎？
我覺得這是很好的，遠比尖括弧好。首先看到括弧向前看一次就完事，沒有ambiguity（也就是parser架構不會太複雜。連關鍵字都覺得影響速度則完全不可理喻）。其次「type」是關鍵字，高亮出來辨識度也夠高。而且type abstraction和value abstraction遵循類似的語法也是很consistent的。事實上在OCaml也可以這麼幹：
fun (type a) -&> …
所以這個type abstraction沒毛病。
用圓括弧做type application好嗎？
不行啊，完全不行啊（大霧。看看上面type abstraction的優點：
- 沒了type關鍵字，說好的parser要快呢？
- 沒了type關鍵字，你讓我怎麼一眼區分type/value application呢？指望semantic highlighting？
- 和type abstraction的consistency去哪了呢？
讓我們再看看OCaml… 哦，人家沒有type application，人家可以全部推斷出來（弱是原罪（指type system
所以你都搞出個挺不錯的type abstraction語法了，type application這麼搞是想不開嗎？type application也要求個type關鍵字很難嗎？什麼？boilerplate？Go會擔心用戶寫的boilerplate太多麼（霧
總結：type abstraction和application都要求type關鍵字我就開吹了，只搞一半就讓人心情複雜……
為了保證編譯速度而不引入新的符號著實沒看懂，我尋思這也幾乎影響不了什麼編譯速度，最影響編譯速度是後端，純粹是編譯器團隊懶得改 parser 的藉口罷了，好一個大道至簡，編譯器團隊的工作量的確大減，不過和用戶沒什麼關係。
Foo(int, int)(a, b)
不過這麼設計下來自己給自己挖坑，用 &其實都已經有潛在的 generics instantiation 和 tuple construction 的二義性問題，這倒好直接用()，我倒是對 Go 以後如何處理 generics instantiation 和 currying function call 的二義性挺感興趣的。
不過我覺得處理方式大概率會是：「Go 是工程語言，大道至簡，不需要這些特性」
更新：
Go 團隊果然發現了二義問題，現在要給類型參數加 type 關鍵字，逐漸變成了 VB 的樣子。
再次更新：
Go 團隊已經決定把小括弧換成中括弧了，官方打了那些口口聲聲說用小括弧好的人的臉，不過官方就這麼不想加新的 token 嗎（逃
知乎這個問題提問的時候的「最新設計」是指：https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md 也就是以contract的概念去實現泛型。
但contract這個方式在9月下旬已經被官方放棄了，現在最新設計是：https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md 即以類型參數的來實現泛型。
從語法上看，前一份基於contract的設計，泛型函數要這麼定義：
func Print(type T)(s []T) {
// same as above
}
而最新的類型參數則是：
func Print[T any](s []T) {
// same as above
}
區別在於：
- 木有type關鍵字
- 不使用小括弧，改成方括弧
這個問題下很多回答都是在吐槽上一份設計中使用小括弧，質問官方為什麼不像Java等語言那樣使用尖括弧，這個問題go官方在新設計中也給出了更為詳細的回答。
go是支持多重賦值的，如果使用使用尖括弧的話，那麼可以參考下面的代碼例子：
a, b = w &< x, y &> (z)
上面的代碼在不知道w的類型的時候，實際上是具有二義性的，它如果是一個變數，那麼上面這行代碼可以被認為是：
- w 跟 x 比較，然後賦值給a
- y 跟 z 比較，然後賦值給b
而如果是w是函數的話，那麼則是：
- 將x, y作為泛型類型參數，z是參數
- 調用w函數
- 函數會有兩個返回值分別賦值給a 跟 b
所以，如果要使用尖括弧的話，go編譯器在做語法解析parsing的時候，便需要獲得變數的類型信息，而這對於go的編譯器來說是一個非常關鍵的設計決定。
我感覺go官方既懶得給編譯器做大改，也不覺得改完之後會更好，因此就採用方括弧這一方案啦~
突然想起朋友的一個評價
「Go 通過把語法搞得極醜從而造就一種自己很底層的錯覺」
實際上自帶runtime/vm 還不如JVM battle tested
有點兒圓胖腫
推薦閱讀：
