『每周譯Go』寫(xiě)了 50 萬(wàn)行 Go 代碼后，我明白這些道理

早在 2019 年 12 月，我第一次寫(xiě)一個(gè)關(guān)于 Goliath 的可汗學(xué)院的項(xiàng)目，該項(xiàng)目的目的是將我們的后端從 python2 整體遷移到 Go 編寫(xiě)的服務(wù)上，以及在該過(guò)程中的一些其他必要的改變。另外，我也寫(xiě)了一篇關(guān)于我們是如何逐步實(shí)現(xiàn)這種改變的博客。

當(dāng)我們開(kāi)始 Goliath 的時(shí)候，我們團(tuán)隊(duì)沒(méi)有一個(gè)人知道 Go，直到我們進(jìn)行實(shí)驗(yàn)才發(fā)現(xiàn)相比于其他語(yǔ)言，Go 對(duì)我們來(lái)說(shuō)是最好的選擇。今天，我們所有的后端和全棧工程師都在寫(xiě) Go ，Goliath 的增量交付讓我們跨越了一個(gè)重大的里程碑：目前，超過(guò) 50 萬(wàn)行 Go 代碼運(yùn)行在我們的生產(chǎn)環(huán)境中。這似乎是一個(gè)對(duì) Go 本身進(jìn)行反思的好時(shí)機(jī)。

我們的工程師喜愛(ài) Go 語(yǔ)言

我向 Go 工程師詢問(wèn)了一些關(guān)于 Go 的開(kāi)放式問(wèn)題，我聽(tīng)到的反饋是 “讀起來(lái)和寫(xiě)起來(lái)都很容易” 和 “我越用越喜歡!”。

一位工程師在 .NET 領(lǐng)域工作多年，推崇 exception 風(fēng)格的錯(cuò)誤處理，這與 Go 的錯(cuò)誤處理非常不同。如果你對(duì)這方面不熟悉，你可以理解為 Go 的錯(cuò)誤都是存在錯(cuò)誤條件的函數(shù)的返回值。我們的前.NET 工程師現(xiàn)在說(shuō)，“能夠調(diào)用一個(gè)沒(méi)有返回錯(cuò)誤的函數(shù)，并且確信它一定會(huì)成功，這真的很棒。

另外一個(gè)工程師引用了 Go 的標(biāo)準(zhǔn)庫(kù)文檔。他喜歡 可以通過(guò) go doc io.Writer等方式獲得離線瀏覽文檔體驗(yàn)。100% 最好的文檔，可以反復(fù)閱讀。

Renee French 的吉祥物地鼠也因給這門(mén)語(yǔ)言帶來(lái)了樂(lè)趣和可愛(ài)而備受贊譽(yù)。

總的來(lái)說(shuō)，Go 工具很棒。編譯速度很快，并且將格式化作為標(biāo)準(zhǔn)工具鏈的一部分，這有助于消除大多數(shù)關(guān)于格式化的爭(zhēng)議。盡管我仍在互聯(lián)網(wǎng)上看到關(guān)于 Go module 的抱怨，但是它比以前的 Go 包管理工具要好很多，關(guān)于這包管理一塊，從我們的經(jīng)驗(yàn)來(lái)看整體上還算不錯(cuò)。我們還可以毫不費(fèi)力找到所需的工具和庫(kù)，比如 gqlgen。

我們想要泛型，不然的話 Go 有點(diǎn)冗長(zhǎng)

大多數(shù)時(shí)候，沒(méi)有泛型寫(xiě) Go 代碼是可以的。但也有很多時(shí)候，當(dāng)我們?cè)趯?xiě)內(nèi)部庫(kù)代碼或者當(dāng)我們?cè)谑褂?slices 的時(shí)候，我們會(huì)感受到泛型的缺失。

缺少泛型是人們對(duì) Go 的最大抱怨。我調(diào)查過(guò)的工程師，他們對(duì)于 Go 團(tuán)隊(duì)花時(shí)間來(lái)開(kāi)發(fā)適合 Go 的泛型這一事實(shí)，非常欣賞。我們對(duì)這項(xiàng)工作的進(jìn)展也感到興奮。等到 Go 泛型正式發(fā)布的時(shí)候，我們至少還得花幾年功夫去使用。

在移植 python 代碼時(shí)，一位工程師指出，對(duì)于特定的語(yǔ)言結(jié)構(gòu)使用 Go 語(yǔ)言花費(fèi)更多的努力，但是 Go 相對(duì)較少的語(yǔ)言特性使得代碼更加一致，閱讀速度更快。對(duì)于我們系統(tǒng)的某一部分，和 python 代碼相比，我們需要 2.7 倍的 Go 代碼來(lái)處理同樣的特性。雖然這部分是由于用跨服務(wù)查詢替換了一些函數(shù)調(diào)用。

另外一個(gè)工程師希望能夠更好地利用高階函數(shù)，這個(gè) slices 包的提議是對(duì)這方面很好的補(bǔ)充。最終，我們希望能少寫(xiě)一點(diǎn)代碼，而選擇泛型將對(duì)此有所幫助。

性能和并發(fā)

從 python（不少是 python2）轉(zhuǎn)過(guò)來(lái)，我們發(fā)現(xiàn) Go 的性能表現(xiàn)非常出色。我們盡可能按照 1:1 的方式將 python 移植到 Go，直到最后會(huì)得到類(lèi)似 Go 的東西，而不是像 Python-in-Go 那樣的代碼。在這個(gè)過(guò)程中，我們沒(méi)有明確地以性能優(yōu)先，除非有真正性能瓶頸。

一位工程師指出，某些批量數(shù)據(jù)更改在 python 版本中每小時(shí)會(huì)產(chǎn)生大約 100 多個(gè)谷歌云數(shù)據(jù)存儲(chǔ)（Google Cloud Datastore）爭(zhēng)用告警，而在 Go 版本中幾乎沒(méi)有，因?yàn)?Go 的處理數(shù)據(jù)速度非常快。我們有一個(gè)異常的例子，一個(gè)包含 1000 個(gè)學(xué)生的類(lèi)，在 python 中加載需要 28 秒，而在 Go 中只需要 4 秒。

雖然我們是從主要為單線程的 python 直接移植過(guò)來(lái)，但是我們已經(jīng)使用了一些 Go 的并發(fā)特性。一位工程師指出，雖然通道是 Go 中的一個(gè)非常突出的特性，但是我們使用 sync 包的功能遠(yuǎn)遠(yuǎn)多于通道。看看我們這個(gè)偏好是不是隨著時(shí)間推移而改變，這會(huì)非常有意思。

寫(xiě)完 50 萬(wàn)行 Go 代碼后

總結(jié)：

• 是的，Go 通常比 python 更冗長(zhǎng) ...

• 但是我們喜歡它，它速度快，工具穩(wěn)定，而且在生產(chǎn)中運(yùn)行良好

我們的工程師來(lái)自不同的編程背景，所以我們對(duì)于 Go 和其他語(yǔ)言有著不同的看法。也就是說(shuō)，當(dāng)我們啟動(dòng)一個(gè)項(xiàng)目時(shí)，Go 能夠勝任我們賦予它的工作。我們很感謝 Go 團(tuán)隊(duì)能夠推動(dòng)它的持續(xù)發(fā)展，并且圍繞著它構(gòu)建社區(qū)。