業內大佬怒噴：Go 正朝著錯誤的方向發展
大家好，國外知名開源大佬 Aliaksandr Valialkin[1]，最近針對即將正式發布的 Go1.23 中的迭代器寫了篇文章[2]怒噴。引起了巨大的社區熱議。
迭代器這一新特性，有認同也有否定。無論怎么說，Go 新的復雜度來了。今天分享他針對 Go 在 rsc 當權后的現狀的看法和對迭代器的不滿等看法的文章。
本文原作者 Aliaksandr Valialkin 是 vm、quicktemplate、fastjson、fasthttp、fastcache、easyproto 等的開發者，也算是較為資深的 Go 工程師了。
Go 編程語言因其易用性而廣為人知。歸功于其精心設計的語法、特性和工具，Go 使得編寫任意復雜度的易于閱讀和維護的程序成為可能（詳見 GitHub）。
圖片
然而，一些軟件工程師稱 Go 為 “無聊”和 “過時”，因為它缺少像：monads、option types、LINQ、borrow checkers、零開銷抽象、面向方面編程、繼承、函數和運算符重載等特性。
雖然這些特性可能簡化特定領域的代碼編寫，但它們除了帶來好處之外，還有額外的成本。
這些特性通常對腦力鍛煉有好處。但在處理生產代碼時，我們不需要額外的心理負擔，因為我們已經忙于解決業務任務。
所有這些特性的主要成本是：
- ? 僅僅通過閱讀代碼，就更難理解發生了什么；
- ? 調試這樣的代碼變得更加困難，因為需要跳過數十個非平凡的抽象才能到達業務邏輯；
- ? 由于這些特性施加的限制，向這樣的代碼添加新功能變得更加困難。
這可能會顯著減慢甚至停止代碼開發的步伐。這就是 Go 最初沒有這些特性的主要原因。
泛型在 Go1.18 中的引入
不幸的是，這些特性開始出現在最近的 Go 版本中：
泛型已經在 Go1.18 中添加。許多軟件工程師希望在 Go 中添加泛型，因為他們認為這將顯著提高他們在 Go 中的生產力。
自 Go1.18 發布以來已經過去了兩年，但生產力提高的跡象并不明顯。Go 中泛型的總體采用率仍然很低。
為什么？因為在大多數實際的 Go 代碼中并不需要泛型。
另一方面，泛型顯著增加了 Go 語言本身的復雜性。例如，嘗試理解泛型添加后 Go 類型推斷的所有細節。它的復雜性已經非常接近 C++ 類型推斷了。
Go 泛型還缺少 C++ 模板中存在的基本特性，例如，Go 泛型不支持泛型類型中的泛型方法。它們也不支持模板特化和模板模板參數，以及許多其他特性，這些特性需要充分利用泛型編程。
Go 1.23 中的迭代器
Range over functions（范圍函數），即迭代器、生成器或協程，將在 Go 1.23 中被添加。讓我們更仔細地看看這個 “特性”。
如果你不熟悉 Go 中的迭代器，那么請閱讀這篇介紹[3]。
本質上，這是一種語法糖，允許在具有特殊簽名的函數上編寫 for ... range 循環。這聽起來像是一個很棒的特性，不是嗎？讓我們嘗試弄清楚這個特性解決了什么實際問題。
在 Go 中，沒有一種標準的方式來遍歷一系列值。由于缺乏任何約定，最終出現了各種各樣的方法。
每種實現都做了在當時的上下文中最有意義的事，但孤立的決策導致了用戶的困惑。
以下是一些標準庫中存在的不同迭代方式：
? archive/tar.Reader.Next
? bufio.Reader.ReadByte
? bufio.Scanner.Scan
? container/ring.Ring.Do
? database/sql.Rows
? expvar.Do
? flag.Visit
? go/token.FileSet.Iterate
? path/filepath.Walk
? runtime.Frames.Next
? sync.Map.Range
這些函數在迭代的細節上幾乎沒有一致性。即使在簽名上達成一致的函數也不總是同意語義。
例如，大多數返回 (bool, T) 的迭代函數遵循 Go 的常規，即第一個 bool 表示第二個 T 是否有效。
與此相反，runtime.Frames.Next 返回的 bool 表示迭代是否繼續。
當你想要遍歷某些內容時，你首先必須了解你正在調用的特定代碼如何處理迭代。這種不一致性阻礙了 Go 的目標，即在大型代碼庫中輕松移動。
人們經常提到所有 Go 代碼看起來都差不多是一種優勢。但對于具有自定義迭代的代碼來說，這根本不是真的。
同理，這聽起來是合理的 - 在 Go 中有一種統一的方式來遍歷各種類型。但是，關于向后兼容性，Go 的主要優勢之一呢？
所有上述標準庫中的現有自定義迭代器將根據 Go 兼容性規則永遠保留在標準庫中。
因此，所有新的 Go 版本將至少提供兩種不同的方式，在標準庫中遍歷各種類型 - 舊的方式和新的方式。
這增加了 Go 編程的復雜性，因為：
- ? 你需要知道遍歷各種類型時的兩種方式，而不是單一的方式。
- ? 你需要能夠閱讀和維護使用舊迭代器的舊代碼，以及可能使用舊迭代器或新迭代器，或同時使用兩種迭代器類型的新代碼。
- ? 當你編寫新代碼時，需要選擇適當的迭代器類型。
Go 1.23 中迭代器的其他問題
直到 Go 1.23，for ... range 循環只能應用于內置類型：int（自 Go1.22 起）、string、slice、map 和 channel。
這些循環的語義清晰易懂（channel 的循環語義更復雜，但如果你處理并發編程，那么你應該很容易理解）。
for ... range 循環現在可以應用于函數，這引入了一種新形式的迭代器，稱為 pull 和 push 函數。
這使得不可能理解給定的無辜循環體 for ... range 實際上在背后做什么，因為它隱式地將循環體包裝在一個匿名函數中，并將其傳遞給 push 迭代器函數。此外，它隱式地調用匿名 pull 函數，并將返回的結果傳遞給循環體。
這還隱式地轉換了 return、continue、break、goto 和 defer 語句為匿名函數內的非顯式語句。
以下是一些示例代碼，展示了新迭代器的使用和潛在問題：
// 舊的顯式回調方法
tree.walk(func(k, v string) { println(k, v) })
// 新的 range over function 方法
for k, v := range tree.walk { println(k, v) }請記住，后面的循環隱式地轉換為帶有顯式回調調用的前一個代碼。現在讓我們從循環中返回一些東西：
for k, v := range tree.walk {
if k == "foo" {
return v
}
}它隱式地轉換為類似于以下內容的難以追蹤的代碼：
var vOuter string
needOuterReturn := false
tree.walk(func(k, v string) bool {
if k == "foo" {
needOuterReturn = true
vOuter = strings.Clone(v) // 這里進行了內存分配和復制
return false
}
})
if needOuterReturn {
return vOuter
}如果 tree.walk 通過從字節切片的不安全轉換將 v 傳遞給回調，那么 v 的內容可能在下一次循環迭代中改變。因此，隱式生成的防彈代碼必須使用 strings.Clone()，這可能導致不必要的內存分配和復制。
range over func 特性對函數簽名施加了限制。這些限制并不適合所有需要迭代集合項的情況。
這迫使軟件工程師在 for ... range 循環的丑陋 hack 和編寫理想適合給定任務的顯式代碼之間做出艱難選擇。
結論
遺憾的是，Go 開始朝著增加復雜性和隱式代碼執行的方向發展。也許我們需要停止添加增加 Go 復雜性的特性，而應該專注于 Go 的基本特性 - 簡單性、生產力和性能。
例如，最近 Rust 開始在性能關鍵領域取代 Go 的份額。我相信如果 Go 核心團隊專注于熱點循環的優化，如循環展開和 SIMD 使用，這種趨勢可以逆轉。
這不應該太影響編譯和鏈接速度，因為只有一小部分編譯的 Go 代碼需要優化。沒有必要優化所有變體的愚蠢代碼 - 這些代碼即使在優化熱點循環之后，仍然會很慢。
只優化軟件工程師有意編寫的特定模式就足夠了，他們關心他們的代碼性能。
Go 比 Rust 更容易使用。我們為什么要在性能競賽中輸給 Rust？
另一個 Go 可以在不增加語言本身復雜性和使用這些特性的 Go 代碼復雜性的情況下獲得的有用特性的例子，是類似于這個的小生活質量改進。
我是誰？
我是 VictoriaMetrics、quicktemplate、fastjson、fasthttp、fastcache、easyproto 等的開發者。感謝 Go，我一直在嘗試遵循 KISS 設計原則。
引用鏈接
[1] Aliaksandr Valialkin: https://github.com/valyala
[2] 文章: https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1a620
[3] 介紹: https://bitfieldconsulting.com/posts/iterators
