[[280313]]

大概每個開發人員應該都會認為自己使用的語言是世界最好的語言吧。這都相對來說的。對于每個人應該都是不同的。

眾所周知，知乎早在幾年前就將推薦系統從 Python 轉為了 Go。于是乎，一部分人就說 Go 比 Python 好，Go 和 Python 兩大社區的相關開發人員為此也爭論過不少，似乎，誰也沒完全說服誰。

知乎從Python轉為Go，是不是代表Go比Python好?我認為，各有優點，誰也取代不了誰，會長期共存!

“由 Python 語言轉向 Go 語言就說明 Go 語言比 Python 語言好”完全是一種片面理解。

“語言至上論”是解決不了業務問題的，選 Go 也不行，Java 也不行。

Go 的優勢是文件易部署，協程機制相對成熟且簡單，以及靜態編譯語言的效率，還有就是編程模式相對簡單。這大概是現在越來越多企業嘗試Go的原因，除了知乎，B 站也把核心部件從 PHP 轉到了Go。

除此之外，BAT 等互聯網巨頭，內部都有系統采用了 Go 語言。

那是不是說 Python、PHP 不行了?當然不是也不應該是這樣的。如果要堅持Python、PHP，也是沒問題。一個系統沉積太久的話，會產生很多大大小小、零零散散的“技術債”，這其間就涉及解決成本的考量，重構、重寫、抑或重新設計核心模塊或新模塊?由此又帶來技術選擇的問題。還有Python、PHP人才儲備的問題，還有團隊希望嘗試新技術的考慮。這些問題交織在一起，就不是哪個編程語言好跟壞這么簡單的事兒了。所以還是要回到業務層面來看技術解決之道。

不得不說，Go的協程，一個“go”就能解決絕大多數問題，確實寫代碼很簡潔，Python 新添的 asyncio 還是相對復雜，Future、Task等等還是有不少門道的。所以，技術永遠只有合適的，而沒有最佳的，也沒有非此即彼的好壞分明。

我相信，如果團隊在 Python 方面積累厚實，且熱衷專注于 Python，選擇Python 應該就是個大概率事件。Python 現在已經應用頗廣，特別是在 AI 領域帶動下，Python 人才也不像以前那樣難找工作了，鐵打的營盤流水的兵，是不是知乎也面臨人才流動壓力?此外，畢竟 Python 的生態，在這么多編程語言中，是數一數二的，Go 雖熱，但在社區方面恐怕還是比不上 Python、PHP，這也是一個現實問題。知乎前端換了 React，我沒感覺比原來的 AngularJS 進步，但不能就此說 React 不行。嘗試用 Go 寫一些原來 Python 的范圍，也是同理。而且一個系統同時應用多種開發語言、一系列技術棧，都是再正常不過的事了。

Python 有自己的場景，不會被徹底替換的，擔心也是多慮的，反正都是“增刪改查”嘛!

至于，知乎為什么選擇 Go，內部的一些工程師透露：選擇 Go 并不是一個人的決定，而是整個團隊深思熟慮后的結果!

眾所周知，知乎社區后端的主力編程語言是 Python。

隨著知乎用戶的迅速增長和業務復雜度的持續增加，核心業務的流量在過去一年內增長了好幾倍，對應的服務端的壓力也越來越大。隨著業務發展，我們發現 Python 作為動態解釋型語言，較低的運行效率和較高的后期維護成本帶來的問題逐漸暴露出來：

運行效率較低。知乎目前機房機柜空間已經不足，按照目前的用戶和流量增長速度，可預見將在短期內服務器資源告急(針對這一點，知乎正在由單機房架構升級為異地多活架構);

Python 過于靈活的語言特性，導致多人協作和項目維護成本較高

受益于近些年開源社區的發展和容器等關鍵技術的普及，知乎的基礎平臺技術選型一直較為開放。在開放的標準之上，各個語言都有成熟的開源的中間件可供選擇。這使得業務做選型時可以根據問題場景選擇更合適的工具，語言也是一樣。

基于此，為了解決資源占用問題和動態語言的維護成本問題，我們決定嘗試使用靜態語言對資源占用極高的核心業務進行重構。

為什么選擇 Golang?

如上所述，知乎在后端技術選型上比較開放。在過去幾年里，除了 Python 作為主力語言開發，知乎內部也不乏 Java、Golang、NodeJS 和 Rust 等語言開發的項目。

Golang 是當時知乎內部討論交流最活躍的編程語言之一，考慮到以下幾點，知乎決定嘗試用 Golang 重構內部高并發量的核心業務：

• 天然的并發優勢，特別適合 IO 密集應用
• 知乎內部基礎組件的 Golang 版生態比較完善
• 靜態類型，多人協作開發和維護更加安全可靠
• 構建好后只需一個可執行文件即可，方便部署
• 學習成本低，且開發效率較 Python 沒有明顯降

相比另一門也很優秀的待選語言—— Java，Golang 在知乎內部生態環境、部署的方便程度和工程師的興趣上都更勝一籌，最終我們決定，選擇 Golang 作為開發語言。

最后，我們做個簡單總結：第一點，重構語言的選擇，關鍵要跟公司技術背景和業務場景結合起來;第二點，架構盡量靈活，并不斷自我迭代;第三點，監控要早點開展，并盡可能底層化、通用化。