Golang 的藝術、哲學和科學_宇宙之一粟

theme: channing-cyan

持續創作，加速成長！這是我參與「掘金日新計劃 · 6 月更文挑戰」的第 24 天，點擊查看活動詳情

早在 2013 年，當我第一次瞭解 Golang 編程語言時，我就面臨着一種“to be or not to be”的問題。

雖然它不像哈姆雷特那樣具有生命意義，但對我來説仍然幾乎是形而上學的。

當任何項目的幾乎所有技術都捆綁在一起時，為什麼我們需要另一種技術？

作為一名 Java 後端開發人員，我對此非常好奇，並決定試一試。

掌握一種或多種輔助語言以輕鬆處理副任務總是有用的，因此 Go - 靜態類型的編譯編程語言 - 似乎是一個很棒的候選者。

所以最大的問題是 Go or not to Go?

我將分享我對為什麼應該認真考慮 Golang 的見解，並將解釋（不加糖衣）為什麼它是一門具有挑戰性但美麗的語言。

讓我們從事實開始：下圖表明 Golang 目前正在搶盡風頭。

在 2019 年，GO 正在迅速成為開發人員最喜歡的技術，從而使其在既定技術（例如 C ++，Python，JavaScript等）中的存在感，

GitHub 指出，是根據 pull 請求的數量，GO 是排名前五的語言之一。

如此受歡迎有幾個原因。我會舉一些例子。

我特別喜歡 Go 的是，它傾向於組合而不是繼承。製作複雜且多層的階級繼承結構不是一個好主意，因為它使您的代碼變得不那麼靈活且難以擴展。

因此，Golang 接口（方法集）系統消除了子類和基於類型的繼承。

儘管如此，Golang 成功的基石還是併發性。它的概念包含在 Go 諺語中，這是一組 Golang 哲學概念。

Go 中的接口與 Java 中的接口非常不同。類型不需要顯式聲明。任何提供接口中命名的方法的類型都可以被視為實現。

Go 使用 goroutines 和通道而不是線程，僅消耗 2KB 內存。

因此，與 Java 線程相比，有機會通過更輕量級和可擴展的部署來轉換數百萬個 goroutine。

Goroutines 之間的通信由 Channel提供，這意味着只有一個 Goroutine 可以在一定時間訪問數據。

這種方法使我們能夠創建異步並行程序，執行任務比以順序編寫的方式更快。

然而，關於 Go 的一切都不是那麼美好。當我深入瞭解 Golang 時，發現它充滿了驚喜。

當你開始學習另一種語言時，總會有挫敗感。

關於 Go 的主要抱怨之一是它的錯誤處理方法，有些人覺得這很有趣。與許多編程語言不同，它沒有標準的異常邏輯。

GO 不允許開發人員在嘗試捕獲塊中包裹代碼。按照慣例，函數將錯誤作為其最後一個返回值。

因此，if err！= nil 語句，要在每個步驟中正確處理它。

if err != nil {\ // handle the error\ }

很多開發人員不喜歡這種看似不變的 nil 檢查。就是為什麼我經常將 Golang 的學習曲線與悲傷的五個階段進行比較。

每一行 Go 代碼都伴隨着一種失望的感覺。我想，“根本不能有這麼多的錯誤檢查！”

但是，如果我們記得 Golang 是為 Google 創建的，那麼可以在這樣的決定中找到一些邏輯。

想象：數百個項目，成千上萬的開發商，數百萬個代碼線。

為了確保一致性和簡單性，創作者擺脱了一些“宂餘”。例如，沒有泛型，這會導致代碼的重用級別降低。

如您所見，簡單性似乎相當複雜。如果有這麼多其他語言都有“正常”的錯誤處理，我為什麼要忍受這個？

儘管我對 Go 很生氣，但我決定朝着“從此幸福快樂”邁進。創作者推薦以下內容：

從理論上講，這聽起來不錯，但在實踐中，通常沒有適當的上下文可以讓開發人員正確處理錯誤。

如果有泛型，那可以幫助解決這個難題。通過利用空接口 (interface {}) 功能，可以實現某種通用機制。

然而，它帶來了很多痛苦，作者自己承認：

在這種不確定的狀態下，許多開發人員與 Golang 分手了。

就個人而言，我認為這是一個巨大的錯誤，因為您不應該在語言本身中尋找答案。

現在，我已經用 Go 寫了 3 年了。我可以説，其中一件棘手的事情是，接受階段不會到來，直到你去進行一個語言可以證明自己的非常大的項目。

Go 是可能性的藝術。這不是關於什麼是最好的或什麼是正確的。這與語言無關。這是關於你可以做些什麼來讓它發揮作用。

一旦你嘗試過這個，你會發現雖然還是一個有爭議的事情，但在實踐中很漂亮。