Go 為什麼不像 Rust 用 ？！做錯誤處理？

大家好，我是煎魚。

之前每次寫 Go 錯誤處理的相關提案時，大家都會在評論區探討到一個事。

Go 這活不得勁，常被戲稱，一個大型 Go 工程專案裡 60% 的程式碼都是 if err != nil。

我們們錯誤處理怎麼不借鑑一下 Rust，高低也整個問號的語法特性，就可以簡化這三行了，不香嗎？

借鑑 Rust 用 ？！| 符號

核心的點是在現有的 Go 例子中，我們一般要寫 if err != nil，多了之後又多又雜看起來還有些麻煩。

如下 Go 程式碼：

count, err = fd.Write(bytes)
if err != nil {
    return nil, err
}

如果我們也借鑑 Rust 使用 ! 和 ？的簡化版，我們可以演進為如下程式碼：

count := fd.Write!(bytes)

count := fd.Write(bytes)!

count := fd.Write(bytes)?

也有大佬提到可以演進一下使用 || 變成：

fd.Write(bytes) || Expr

不管如何，就是不需要寫三行的 if err != nil 去處理這個硬邏輯，只要加個符號（類似語法糖）就行，由編譯器和執行時自己去處理就完了。

這類提案都會被拒絕

為什麼最後 Go 沒有落地呢？

普遍社群中參與討論的大佬認為，新的語法糖相較 if err != nil，會增加認知和理解程式碼的開銷，並降低程式碼可讀性。

這些神奇的的功能和符號，他們是隱秘的，更容易讓人錯過，會導致程式控制流邏輯發生改變，增加程式設計師的心智負擔。

Go 初學者也需要額外掌握這幾個符號的理解和應用，有新的學習成本。

這類提案會被直接拒絕，請大家不要再幻想了。

希望開發者自己定模板

如果只是為了解決那 3 行程式碼，部分大佬表示 Go 開發者應該自己定義錯誤模板。而不是藉助引入更多的新語法來解決，這也不符合 Go 語言對 “less is more” 的理念定義。

從現在對 Go 錯誤處理的多個提案討論和社群交流來看，Go 在這塊已經陷入僵局，很像工作中的什麼呢？

像我們常提的既要也要還要，重要的是這事 ROI 也不夠高，導致Go 核心團隊的動力不足，也不想互相得罪了。

只能甩出一句經典：”讓 Rust 特性留給 Rust“。

總結

Go 錯誤處理 if err != nil 的解決，已經成為了一塊燙手的山芋，怎麼改都不討好了，相關負責人積極討論，實施持續擺爛中，沒有新的建設。

根據以往在依賴管理的，我猜測最終大機率會由 Go 團隊大當家 Russ Cox 操刀，否則很難有人能力挽狂瀾。不過，目前來看他對此並不感興趣。對於開啟 Go 工具鏈遙測的提案，也剛吃了閉門羹。

錯誤處理的碰撞，真是 Go 的一生之敵。