[[429975]]

作為兩門服務端的新語言，這些年受到越來越多的關注。有人調(diào)侃說，關注 Rust 的人中，很大一部分是從 Go 過來的。經(jīng)常有人因為 Go 的一些設計和特質(zhì)而質(zhì)疑它，同時，Rust 常被譽為解決 Go 問題的幾乎完美設計的替代方案。但實際上，這兩門語言并不是直接競爭關系，不能直接互換，更多是互補。本文就帶著大家看看兩者的不同。

有一篇文章 《I want off Mr. Golang's Wild Ride》：https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride，以及圍繞它的激烈討論，不止一次遇到過諸如“Rust 是 Go 應該成為的樣子”之類的陳述。這些討論中觀點，顯然是由那篇文章推動的，似乎反應出 Go 有太多有問題的特性，而另一方面，Rust 是一個精心設計的 Go 替代品。

在我看來，這篇文章的討論揭示了對這兩種語言、它們解決的問題以及它們所針對的軟件開發(fā)范式的嚴重誤解。

01 文章對 Go 的批評

這篇文章主要批評 Go 的簡單是一個謊言：標準庫中的 API 向用戶隱藏了復雜性，而沒有真正解決它，這在極端情況下會產(chǎn)生完全錯誤的結果。以 Go 的 filepath.Ext 函數(shù)為例：它在某些情況下會產(chǎn)生不準確的結果。作為反例，這篇文章提到了 Rust std::path::extension 是產(chǎn)生完全正確結果的函數(shù)。

這種對 Go 在邊緣情況下不準確的不滿似乎是可以理解的。我們都知道，在編程中，只有正確和不正確，沒有其他結果。因此，由于 Rust 提供了正確的結果，它顯然是更好的語言。但事情真的這么簡單嗎？難道谷歌不能聘請高手來解決這個問題嗎？

02 追根溯源

Go 和 Rust 被頻繁地比較，因為它們都被宣傳為系統(tǒng)編程語言，而且它們都是現(xiàn)代的編程語言，發(fā)布時間接近。但是，一旦你內(nèi)化了它們的來源以及它們的設計目的，你很快就會發(fā)現(xiàn)它們是兩種完全不同的語言。

Go 是一個 Google 項目，主要設計用于后端和網(wǎng)絡服務。這些服務在可預測的、同質(zhì)的、Unix 等基礎設施中運行。谷歌完全控制著他們的基礎設施，潛在的性能瓶頸可以通過在問題上投入更多的服務器來解決。

另一方面，Rust 是由 Mozilla 在非常不同的情況下啟動的。Firefox 和 Servo 等項目是非常長壽的軟件產(chǎn)品，必須在各種系統(tǒng)上運行。他們必須在不均勻、未知且可能充滿惡意的環(huán)境中工作。因此，在每個系統(tǒng)上產(chǎn)生完全相同的結果對于這些應用程序至關重要。

03 不同的問題，不同的語言

谷歌和許多其他維護類似基礎設施的公司通常必須應對以下挑戰(zhàn)——雖然我對谷歌沒有深入的了解，但其中一些可能被其龐大的規(guī)模放大了：

• 開發(fā)人員流動率高。

• 短迭代中的快節(jié)奏開發(fā)。

• 快節(jié)奏的組織擴展。

• 高度動態(tài)的基礎設施和環(huán)境。

• 短期和可替換的服務。

Google 需要一種完全針對這些挑戰(zhàn)量身定制的語言，并且不可避免地會設計出與滿足 Mozilla 需求的語言不同的語言。

04 另一種范式

Go 和 Rust 不僅有不同的語言設計，它們還包含一種相反的軟件開發(fā)方法。Rust 專注于高效率并為問題找到最漂亮的實現(xiàn)。為了實現(xiàn)這一點，與其他語言相比，它有著更陡峭的學習曲線。

相比之下——這就是大部分行業(yè)的現(xiàn)實——谷歌和許多其他公司不希望他們的開發(fā)人員在他們能夠高效工作之前花 3 個月時間學習一門新語言。因此，Go 被有意設計為一種快速學習和使用的語言。它不一定是最有效或最漂亮的解決方案。它甚至不必在公司不使用的系統(tǒng)上工作。它只需要工作得足夠好。

為什么？因為運行動態(tài)基礎設施需要高度的自動化、標準化、監(jiān)控、可觀察性、彈性、可擴展性和安全性。對于不在這樣的環(huán)境中工作的開發(fā)人員來說，這聽起來可能很奇怪，但在日常業(yè)務中，重點往往是這些高級需求而不是代碼本身。

05 底線

盡管乍一看 Go 和 Rust 似乎為類似場景提供了類似的好處，但它們是針對不同問題而設計的專業(yè)工具。就像大多數(shù)其他工具一樣，一個并非比另一個“更好”。在尋找適合自己需求的新語言時，Google 和 Mozilla 都沒有采取有偏見的方法。他們只是努力尋找最適合他們的解決方案——你也應該如此。