大家好，我是煎魚。
之前每次寫 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 也不夠高。
讓 Rust 特性留給 Rust。
總結
Go 錯誤處理 if err != nil 的解決，已經成為了一塊燙手的山芋，怎麼改都不討好了，相關負責人積極討論，實施持續擺爛中。
根據以往在依賴管理的，我猜測最終大機率會由 Go 團隊大當家 Russ Cox 操刀，否則很難有人能力挽狂瀾。
錯誤處理的碰撞，真是 Go 的一生之敵。
文章持續更新，可以微信搜【腦子進煎魚了】閱讀，本文 GitHub github.com/eddycjy/blog 已收錄，學習 Go 語言可以看 Go 學習地圖和路線，歡迎 Star 催更。