寫了 50 萬行 Go 程式碼後，我明白這些道理

寫了 50 萬行 Go 程式碼後，我明白這些道理

• 原文地址：https://blog.khanacademy.org/half-a-million-lines-of-go/
• 原文作者：Kevin Dangoor

• 本文永久連結：https://github.com/gocn/translator/blob/master/2021/w22_half_a_million_lines_of_go.md

• 譯者：朱亞光

早在 2019 年 12 月，我第一次寫一個關於 Goliath 的可汗學院的專案，該專案的目的是將我們的後端從 python2 整體遷移到 Go 編寫的服務上，以及在該過程中的一些其他必要的改變。另外，我也寫了一篇關於我們是如何逐步實現這種改變的部落格。

當我們開始 Goliath 的時候，我們團隊沒有一個人知道 Go，直到我們進行實驗才發現相比於其他語言，Go 對我們來說是最好的選擇。今天，我們所有的後端和全棧工程師都在寫 Go ，Goliath 的增量交付讓我們跨越了一個重大的里程碑：目前，超過 50 萬行 Go 程式碼執行在我們的生產環境中。這似乎是一個對 Go 本身進行反思的好時機。

我們的工程師喜愛 Go 語言

我向 Go 工程師詢問了一些關於 Go 的開放式問題，我聽到的反饋是 “讀起來和寫起來都很容易” 和 “我越用越喜歡!”。

一位工程師在 .NET 領域工作多年，推崇 exception 風格的錯誤處理，這與 Go 的錯誤處理非常不同。如果你對這方面不熟悉，你可以理解為 Go 的錯誤都是存在錯誤條件的函式的返回值。我們的前.NET 工程師現在說，“能夠呼叫一個沒有返回錯誤的函式，並且確信它一定會成功，這真的很棒。

另外一個工程師引用了 Go 的標準庫文件。他喜歡 可以通過 go doc io.Writer等方式獲得離線瀏覽文件體驗。100% 最好的文件，可以反覆閱讀。

Renee French 的吉祥物地鼠也因給這門語言帶來了樂趣和可愛而備受讚譽。

總的來說，Go 工具很棒。編譯速度很快，並且將格式化作為標準工具鏈的一部分，這有助於消除大多數關於格式化的爭議。儘管我仍在網際網路上看到關於 Go module 的抱怨，但是它比以前的 Go 包管理工具要好很多，關於這包管理一塊，從我們的經驗來看整體上還算不錯。我們還可以毫不費力找到所需的工具和庫，比如 gqlgen。

我們想要泛型，不然的話 Go 有點冗長

大多數時候，沒有泛型寫 Go 程式碼是可以的。但也有很多時候，當我們在寫內部庫程式碼或者當我們在使用 slices 的時候，我們會感受到泛型的缺失。

缺少泛型是人們對 Go 的最大抱怨。我調查過的工程師，他們對於 Go 團隊花時間來開發適合 Go 的泛型這一事實，非常欣賞。我們對這項工作的進展也感到興奮。等到 Go 泛型正式釋出的時候，我們至少還得花幾年功夫去使用。

在移植 python 程式碼時，一位工程師指出，對於特定的語言結構使用 Go 語言花費更多的努力，但是 Go 相對較少的語言特性使得程式碼更加一致，閱讀速度更快。對於我們系統的某一部分，和 python 程式碼相比，我們需要 2.7 倍的 Go 程式碼來處理同樣的特性。雖然這部分是由於用跨服務查詢替換了一些函式呼叫。

另外一個工程師希望能夠更好地利用高階函式，這個 slices 包的提議是對這方面很好的補充。最終，我們希望能少寫一點程式碼，而選擇泛型將對此有所幫助。

效能和併發

從 python（不少是 python2）轉過來，我們發現 Go 的效能表現非常出色。我們儘可能按照 1:1 的方式將 python 移植到 Go，直到最後會得到類似 Go 的東西，而不是像 Python-in-Go 那樣的程式碼。在這個過程中，我們沒有明確地以效能優先，除非有真正效能瓶頸。

一位工程師指出，某些批量資料更改在 python 版本中每小時會產生大約 100 多個谷歌雲資料儲存（Google Cloud Datastore）爭用告警，而在 Go 版本中幾乎沒有，因為 Go 的處理資料速度非常快。我們有一個異常的例子，一個包含 1000 個學生的類，在 python 中載入需要 28 秒，而在 Go 中只需要 4 秒。

雖然我們是從主要為單執行緒的 python 直接移植過來，但是我們已經使用了一些 Go 的併發特性。一位工程師指出，雖然通道是 Go 中的一個非常突出的特性，但是我們使用 sync 包的功能遠遠多於通道。看看我們這個偏好是不是隨著時間推移而改變，這會非常有意思。

寫完 50 萬行 Go 程式碼後

總結：

• 是的，Go 通常比 python 更冗長 ...
• 但是我們喜歡它，它速度快，工具穩定，而且在生產中執行良好

我們的工程師來自不同的程式設計背景，所以我們對於 Go 和其他語言有著不同的看法。也就是說，當我們啟動一個專案時，Go 能夠勝任我們賦予它的工作。我們很感謝 Go 團隊能夠推動它的持續發展，並且圍繞著它構建社群。