[[431027]]

 大家好，我是煎魚。

前段時間社區里一下子就爆了，主要是各大媒體引用了 Go 語言之父 Rob Pike 所提的《go: don't change the libraries in 1.18》。

很多社交媒體都做了跟進，認為 Rob Pike 是硬性的反對 Go 泛型的 API 改造!

如果讀者只看了標題，有可能會產生一些誤解實際上其表達的意思和近期 Go 社區討論的事項是有關聯的，要一起綜合來看。

為此，今天煎魚就和大家一起來理一理，看看 Go 泛型 API 的改造工程，是個怎么一回事?

現狀

馬上就是 2021.11 月，連深圳都變冷了...根據 Go 語言的發布周期，Go1.18 版本的發布，那就是 2022.02 月左右。

現在給到 Ian Lance Taylor、 Robert Griesemer 等大佬僅剩 3 個月的時間給大家討論泛型細節，進一步完善實現，達到生產可用。

拋出 Go 泛型的實現進度不說，現在遇到了一個比較大的問題。那就是實現泛型后 ”如何更新泛型的 API“。

這之中包含好幾個方面，分別是：既有標準庫、開源庫，新標準庫等。不同庫之間是不同的人在維護。

但這里存在一個大問題，如下圖：

Russ Cox 在 9 月就提出了 ”how to update APIs for generics“ 的疑惑，當時顯然這一塊還沒有共識。在 11 月的現在，從討論的記錄來看，怎么做還沒有達成一個最終的明確共識(初步已有，未正式答復)。

但存在一個問題，Go 社區對于泛型的迫切度，熱情非常高，各種泛型化的標準庫的提案都提出來了，推著設計者往前走。

爭議

結合來看 Rob Pike，更多是：建議和提醒 Go 社區和核心開發團隊，要 ”悠著點“，Go1.18 想支持泛型，做完成庫的改造，還得代價小，畢竟細節很多。

引用其理由，核心論據是：

在一個版本中，做泛型、標準庫等，要做的事情太多，很可能會弄錯。

• 沒有在 Go 中使用新類型的經驗，無法為其設計提供有力的依據。
• Go1 兼容性的承諾，在任何細節上出錯的代價都很高，要等待、觀察和學習。
• 和一句諺語很接近：”不要一口氣吃胖子“，何況沒有相關的經驗，都只是詳細的推理、預演，需要晉升。

在 Go issues 中也有人吐槽，1.18 空有泛型的實現。其他配套的標準庫等都沒有，那這個 Go1.18 出來的泛型意義是?

后續

雖然還沒有最終拍板，但是根據討論的過程和社區贊同數(??)來看，如下：

后續仍然會設計、構建、測試和使用用于切片(Slice)、地圖(Map)、通道(Channel)等的新庫。

這些庫并沒有生產可用，會把他們放在 golang/x/exp 倉庫中，可以使用，僅作為現階段的實驗性的庫，沒有兼容性保障。

該實驗庫會在一兩個周期內會改變、調整和發展。能夠讓 Go 社區的開發者們嘗試一下使用，以便接受更多的意見。

再根據使用者的反饋通過經驗和分析進行更新，就會把它們移到主倉庫中，才達到正式生產可用的級別。

總結

在今天這篇文章中，我們針對 Rob Pike 為什么會要調整 Go 泛型后的標準庫 API 等的提議進行了分析。

為此我們了解到 Go 核心團隊對 ”how to update APIs for generics“ 的顧慮，以及現有社區的激情，綜合來看，給出的逐步演進的泛型方案建議。

以此可知，Go 完整泛型(含配套庫)的生產可用，可能還要經歷幾個 Go 版本，讓不少人望穿秋水了...