2023 年的 Rust 與 Go[譯]

本文譯自《Rust vs Go in 2023》[1]。

注：從 2022 年下半年開始，我們研發團隊的產品研發不再侷限於雲端，車端也是將來的一個重要方向。於是我除了繼續對 Go 語言保持常規的高度關注之外，也逐步開始留意 Rust 語言的發展。

Rust 和 Go 哪個更好？Go 還是 Rust？在 2023 年，你應該爲你的下一個項目選擇哪種語言，爲什麼？兩者在性能、簡單性、安全性、功能、規模和併發性等方面如何比較？它們的共同點是什麼，它們有哪些根本性的不同？讓我們在這個友好而公平的 Rust 和 Go 的比較中找到答案。

Rust 和 Go 都很棒

首先，我必須要說的是，Go 和 Rust 都是絕對優秀的編程語言。它們都是現代的、強大的、被廣泛採用的編程語言，並且都提供出色的性能。

你可能讀過一些說 Go 比 Rust 好的文章，或者相反。但這真的沒有意義；每一種編程語言都代表了一系列的權衡和取捨。每種語言都有自己的優化重點，所以你對語言的選擇應該由適合你的東西和你想用它解決的問題決定。

在這篇文章中，我將嘗試告訴你何時使用 Go 是理想選擇以及何時使用 Rust 更佳。我也會試着介紹一下這兩種語言的本質（如果你願意的話，就是 Go 和 Rust 的道 [2]）。

雖然它們在語法和風格上有很大不同，但 Rust 和 Go 都是構建軟件的一流工具。接下來，讓我們仔細看看這兩種語言。

Go 和 Rust 的相似之處

Rust 和 Go 有很多共同點，這也是你經常聽到它們一起被提及的原因之一。兩種語言的共同目標是什麼呢？

Rust 是一種低級靜態類型的多範式編程語言，專注於安全和性能。 - Gints Dreimanis[3]

Go 是一種開源的編程語言，可以輕鬆構建簡單、可靠、高效的軟件。 - go.dev[4]

內存安全

Go 和 Rust 都屬於現代編程語言，它們的首要任務是內存安全。經過幾十年對 C 和 C++ 等舊語言的使用，我們可以清楚地看到，導致錯誤和安全漏洞的最大原因之一是不安全地或不正確地訪問內存。

Rust 和 Go 以不同的方式處理這個問題，但它們的目標都是在管理內存方面比其他語言更聰明、更安全，並幫助你寫出正確 [5] 和高性能 [6] 的程序。

快速、緊湊的可執行文件

Go 和 Rust 都是編譯型語言，這意味着你的程序被直接翻譯成可執行的機器碼，因此你可以以單一二進制文件形式來部署你的程序；與 Python[7] 和 Ruby 等解釋型語言不同，你不需要將解釋器和大量的庫和依賴關係與你的程序一起分發，這是一個很大的優點。這也使得 Rust 和 Go 的程序與解釋型語言相比都非常快。

通用語言

Rust 和 Go 都是強大的、可擴展的通用編程語言，你可以用它們來開發各種現代軟件，從網絡應用到分佈式微服務，或者從嵌入式微控制器到移動應用程序。

兩者都有優秀的標準庫、繁榮的第三方生態系統以及巨大的商業支持和龐大的用戶基礎。它們都已經存在了很多年，並將在未來幾年內繼續被廣泛使用。今天學習 Go 或 Rust 將是對你時間和精力的合理投資。

務實的編程風格

Go 和 Rust 都不是以函數式編程爲主的語言 [8]（例如像 Scala 或 Elixir），也不是完全面向對象的語言（像 Java 和 C#）。相反，雖然 Go 和 Rust 都有與函數式和麪向對象編程相關的特性，但它們是務實的語言，旨在以最合適的方式解決問題，而不是強迫你採用特定的做事方式。

如果你喜歡函數式編程風格，你會在 Rust 中發現更多對這種風格的支持，因爲 Rust 在語法特性數量上要比 Go 更多。

我們可以討論什麼是 “面向對象” 語言，但可以說 C++、Java 或 C# 用戶所期望的面向對象編程風格在 Go 或 Rust 中都不存在。 - Jack Mott

規模化的開發

Rust 和 Go 都有一些有用的特性，使它們適合於大規模的編程，不管是指大型團隊，還是大型代碼庫，或者兩者兼具。

例如，C 語言的程序員們多年來一直在爭論將括號放在哪裏，以及代碼應該用製表符還是空格縮進，而 Rust 和 Go 通過使用標準的格式化工具（Go 爲 gofmt，Rust 爲 rustfmt）使用規範的風格自動重寫你的代碼，完全消除了這些問題。

這並不是說這種特殊的風格本身有多好：而是 Rust 和 Go 的程序員都喜歡這種標準化。

gofmt 的風格是沒有人喜歡的，但 gofmt 卻是所有人的最愛。 - Rob Pike[9]

兩種語言的另一個高分領域是 ** 構建管道 (pipeline)**。兩種語言都有優秀的、內置的、高性能的標準構建和依賴管理工具；不再需要與複雜的第三方構建系統搏鬥，也不再需要每隔幾年就學習一個新的系統。

對於早期職業生涯以 Java 和 Ruby 爲背景的我而言，構建 Go 和 Rust 代碼感覺就像從我的肩上卸下了一個不可能的重擔。當我在谷歌工作時，遇到用 Go 編寫的服務是一種解脫，因爲我知道它很容易構建和運行。Rust 也是如此，儘管我只在較小規模的 Rust 項目上工作過。我希望可無限配置的構建系統的時代已經過去了，所有語言都會有自己專門的構建工具，開箱即可使用。- 山姆 - 羅斯 [10]

Rust 還是 Go？

綜上可知，這兩種語言都設計得很好、很強大，那麼你可能會想知道那些關於兩門語言的 “聖戰” 究竟是怎麼回事（我也是）。爲什麼人們對 “Go vs.Rust” 如此大驚小怪，在社交媒體上大打出手，並且寫長篇博文說只有傻瓜纔會使用 Rust，或者 Go 不是真正的編程語言，或者其他什麼。

這可能會讓他們感覺好些，但這並不能完全幫助你，因爲你正試圖決定在你的項目中使用哪種語言，或者你應該學習哪種語言來推動你的編程生涯。一個明智的人不會根據誰喊得聲最大來做出重要的選擇。

現在讓我們繼續我們成熟的討論，看看在某些領域，一個有理智的人可能更喜歡哪一種語言。

Go 與 Rust 的性能對比

我們已經說過，Go 和 Rust 都能生產出高性能的程序，因爲它們被編譯成了本地機器代碼，而不必通過解釋器或虛擬機。

然而，Rust 的性能尤其突出。它可以與 C 和 C++ 相媲美，這兩種語言通常被認爲是性能最高的編譯語言，但與這些老語言不同的是，Rust 還提供了內存安全和併發安全，並且基本上不會給執行速度上帶去沒有任何開銷。Rust 還允許你創建複雜的抽象，而不需要在運行時付出任何性能上的代價。

相比之下，儘管 Go 程序的性能也非常好，但 Go 主要是爲開發速度（包括編譯）而設計的，而不是執行速度。Go 程序員更傾向於清晰的代碼而不是快速的代碼 [11]。

Go 編譯器也不會花很多時間去嘗試生成最有效的機器代碼；它更關心的是快速編譯大量代碼。所以 Rust 通常會在運行時基準測試中擊敗 Go。

Rust 的運行時性能也是一致和可預測的，因爲它不使用垃圾收集。Go 的垃圾收集器非常高效，並且經過優化，使其 “STW(停止世界)” 的停頓時間儘可能短（每一個新的 Go 版本都會越來越短）。但是垃圾收集不可避免地在程序的行爲方式中引入了一些不可預測的因素，這在某些應用中可能是一個嚴重的問題，例如嵌入式系統。

因爲 Rust 旨在讓程序員完全控制底層硬件，所以有可能將 Rust 程序優化到相當接近機器的最大理論性能。這使得 Rust 在執行速度勝過所有其他考慮因素的領域是一個很好的選擇，比如遊戲編程、操作系統內核、網絡瀏覽器組件和實時控制系統。

簡單性

如果沒有人能夠弄清楚如何使用一種編程語言，那麼這種語言有多快也無所謂。Go 語言是爲了應對 C++ 等語言不斷增長的複雜性而特意設計的；它的語法非常少，關鍵字也非常少，事實上，功能特性也很少。

這意味着學習 Go 語言 [12] 不需要很長時間，就可以用它來編寫有用的程序。

Go 是非常容易學習的。我知道這是一個經常被吹捧的好處，但我真的很驚訝於我能夠如此迅速地提高工作效率。多虧了這個語言、文檔和工具，我在兩天後就寫出了有趣的、可提交的代碼。 - 一個 Rust 程序員對 Go 的早期印象 [13]

這裏的關鍵詞是簡單性。當然，簡單並不等同於容易，但是小而簡單的語言比大而複雜的語言更容易學習。Go 語言沒有提供那麼多不同的方法來做一件事情，所以所有寫得好的 Go 代碼往往看起來都一樣。快速學習一個不熟悉的服務並理解它在做什麼很容易。

fmt.Println("Gopher's Diner Breakfast Menu")
for dish, price := range menu {
    fmt.Println(dish, price)
}

在我的代碼俱樂部視頻系列 [14] 中，我正是這樣做的：從 GitHub 上半隨機地挑選 Go 項目，並與一羣 Go 初學者一起探索它們，看看我們能理解多少的代碼。結果總是比我們預期的要多。

雖然核心語言很小，但 Go 的標準庫卻非常強大。這意味着你的學習曲線也需要包括你需要的標準庫的部分，而不僅僅是 Go 語法。

另一方面，將功能從語言中轉移到標準庫中，意味着你可以只專注於學習與你現在相關的庫。

Go 也是爲大規模的軟件開發而設計的，支持有大型代碼庫的大型團隊。在這種情況下，新的開發人員能夠儘快上手是非常重要的。出於這個原因，Go 社區十分看重：簡單、明顯、常規、直接的程序 [15]。

使用 Go，你可以快速完成工作。Go 是我所使用過的生產力最高的語言之一。它的口號是：今天解決實際問題。 - 馬蒂亞斯 - 恩德勒 [16]

特性

Rust 比其他幾種編程語言支持更多的複雜語法特性，因此，你可以用它實現更多。 - devathon[17]

Rust 是專門設計用來幫助程序員用最少的代碼做最多的事情，它包括很多強大而有用的功能特性。例如，Rust 的 match 功能可以讓你以十分簡潔地方式寫出靈活的、富有表現力的邏輯：

fn is_prime(n: u64) -> bool {
    match n {
        0...1 => false,
        _ => !(2..n).any(|d| n % d == 0),
    }
}

因爲 Rust 做了很多事情，這意味着有很多東西需要學習，特別是在開始的時候。但這沒關係：在 C++ 或 Java 中也有很多東西要學，而且你不會得到 Rust 的高級特性，比如內存安全。

批評 Rust 是一種複雜的語言忽略了一點：它被設計成具有表現力，這意味着有很多功能，而在許多情況下，這正是你想要的編程語言。

當然，Rust 有一個學習曲線，但一旦你開始使用它，你就會好起來。

對於那些準備接受更復雜的語法和語義（以及可能更高的可讀性成本）以換取最大可能的性能的程序員來說，Rust 將與 C++ 和 D 語言爭奪思想份額。 - 戴夫 - 切尼 [18]

雖然 Rust 採用了 Go 的一些特性，而 Go 也在採用 Rust 的一些特性（尤其是泛型 [19]），但可以說 Rust 的特性很重，而 Go 的特性相對較輕。

併發

大多數語言都對併發編程（同時做多件事情）有某種形式的支持，但 Go 從一開始就是爲這項工作而設計的。Go 不使用操作系統的線程，而是提供了一個輕量級的替代方案：goroutine。

每個 goroutine 是一個獨立執行的 Go 函數，Go 調度器會將其映射到其控制下的一個操作系統線程中。這意味着調度器可以非常有效地管理大量併發的 goroutine，只使用有限的操作系統線程。

因此，你可以在一個程序中運行數百萬個併發的 goroutine，而不會產生嚴重的性能問題。這使得 Go 成爲高規模併發應用程序的完美選擇，如網絡服務器和微服務。

Go 還具有快速、安全、高效的功能特性，可以使用 channel 讓 goroutines 進行通信和共享數據。Go 的併發支持感覺設計得很好，使用起來也很愉快。

一般來說，對併發程序進行推斷是很難的，而且在任何語言中建立可靠、正確的併發程序都是一個挑戰。但由於它從一開始就內置於語言中，而不是事後纔想到的，Go 中的併發編程是最簡單、最完整的。

Go 語言可以很容易地建立一個很好的多因素的應用程序，充分利用併發性，同時作爲一組微服務進行部署。Rust 也可以做這些事情，但可以說它更難。在某些方面，Rust 對防止與內存有關的安全漏洞的癡迷意味着程序員必須不遺餘力地執行那些在其他語言（包括 Go）中會更簡單的任務。 - Sonya Koptyev[20]

相比之下，Rust 中的併發故事是非常新的，而且還在穩定中，但它正處於非常積極的開發中，所以請關注這個領域。例如，Rust 的 rayon 庫 [21] 提供了一種非常優雅和輕量級的方式來將順序計算轉化爲並行計算。

擁有 goroutines 和使用 channel 的輕量級語法真的很好。這真的顯示了語法的力量，這些小細節使併發編程比其他語言感覺好得多 - 一個 Rust 程序員對 Go 的早期印象 [22]

雖然在 Rust 中實現併發程序可能不那麼簡單，但還是有可能的，而且這些程序可以利用 Rust 的安全保證。

一個很好的例子是標準庫的 Mutex 類：在 Go 中，你可以忘記在訪問某些東西之前獲得一個 Mutex 鎖，但 Rust 不會讓你這樣做。

Go 專注於將併發性作爲一個一等公民的概念。這並不是說你不能在 Rust 中找到 Go 的面向 actor 的併發性，但這是留給程序員的一個練習。 - Dave Cheney[23]

安全

我們在前面看到，Go 和 Rust 都以不同的方式來防止一大類與內存管理有關的常見編程錯誤。但是 Rust 尤其努力確保你不會做一些你不想做的不安全的事情。

Rust 的編譯器非常嚴格和學究派，它檢查你使用的每個變量和你引用的每個內存地址。它避免了可能的數據競爭條件，並告知你未定義的行爲。併發和內存安全問題在 Rust 的安全子集中根本不可能發生。 - 爲什麼是 Rust？[24]

這將使 Rust 編程成爲與幾乎所有其他語言不同的體驗，而且一開始可能是一種挑戰。但對很多人來說，這種辛苦是值得的。

對我來說，Rust 的關鍵優勢是一種感覺，即編譯器是我的後盾，不會讓它可能檢測到的任何錯誤通過（說真的，有時感覺就像魔法一樣）。 - Grzegorz Nosek

包括 Go 在內的許多語言都有幫助程序員避免錯誤的設施，但 Rust 將這一點提高到了一個新的水平，因此可能不正確的程序甚至不會被編譯。

有了 Rust，庫程序員有很多工具來防止他 / 她的用戶犯錯。Rust 讓我們有能力說，我們擁有一塊特定的數據；其他東西不可能聲稱擁有，所以我們知道沒有其他東西能夠修改它。我想不出以前有什麼時候我被賦予過這麼多工具來防止意外的誤用。這是一種奇妙的感覺。 - 山姆 - 羅斯 [25]

“與借用檢查器 (borrow checker) 鬥爭”是 Rust 程序員新手的常見綜合症，但在大多數情況下，它所發現的問題是你的代碼中真正的 bug（或至少是潛在的 bug）。它可能會迫使你從根本上重構你的程序，以避免遇到這些問題；而當正確性和可靠性是你的首要任務時，這是件好事。

一個不改變你編程方式的語言有什麼意義呢？當你用其他語言工作時，Rust 所教授的關於安全的課程也是有用的。

如果你選擇了 Rust，通常你需要該語言提供的保證：針對空指針和數據競爭的安全，可預測的運行時行爲，以及對硬件的完全控制。如果你不需要這些功能，Rust 可能是你下一個項目的糟糕選擇。這是因爲這些保證是有代價的：入門時間。你需要戒掉壞習慣，學習新概念。有可能的是，當你開始的時候，你會經常和借用檢查器鬥爭。 - Matthias Endler[26]

你覺得 Rust 的編程模型有多大的挑戰性，可能取決於你以前有哪些其他語言的經驗。Python 或 Ruby 程序員可能會發現它的限制性；其他人會很高興。

如果你是一個花了幾周的時間來追尋內存安全漏洞的 C/C++ 程序員，你會非常欣賞 Rust。"與借用檢查器鬥爭" 變成了 "編譯器可以檢測到這個？酷！" -Grzegorz Nosek

規模化

今天的服務器程序由數千萬行代碼組成，由數百甚至數千名程序員進行構建，而且每天都在更新。Go 的設計和開發是爲了使在這種環境中工作更有成效。Go 的設計考慮包括嚴格的依賴性管理，隨着系統的發展，軟件架構的適應性，以及組件之間的健壯性。 - Rob Pike[27]

當你一個人或在小團隊中處理問題時，選擇簡單的語言還是功能豐富的語言是一個偏好的問題。但是當軟件越來越大，越來越複雜，團隊越來越大時，差異就開始顯現出來了。

對於大型應用程序和分佈式系統來說，執行速度不如開發速度重要：像 Go 這樣刻意簡化的語言可以減少新開發人員的啓動時間，並使他們更容易處理大型代碼庫的工作。

有了 Go，作爲初級開發者更容易提高工作效率，而作爲中級開發者則更難引入會導致後續問題的脆弱抽象。由於這些原因，Rust 在企業軟件開發方面不如 Go 有說服力。 - Loris Cro[28]

當涉及到大型的軟件開發時，清晰的比聰明的好。Go 的侷限性實際上使它比 Rust 等更復雜和強大的語言更適合企業和大機構。

Rust 和 Go 的不同點

雖然 Rust 和 Go 都是流行的、現代的、廣泛使用的語言，但它們並不是真正的競爭對手，因爲它們故意針對的是完全不同的使用情況。

Go 的整個編程方法 [29] 與 Rust 的完全不同，每一種語言都適合一些人，同時也會刺激另一些人。這完全沒問題，如果 Rust 和 Go 都能以或多或少相同的方式做同樣的事情，我們就不會真的需要兩種不同的語言。

那麼，我們是否可以通過發現 Rust 和 Go 所採取的截然不同的方法來了解它們各自的本性呢？讓我們拭目以待。

垃圾回收

“要不要垃圾回收” 是一個沒有正確答案的問題。垃圾回收，以及一般的自動內存管理，使得開發可靠、高效的程序變得快速和容易，對於一些人來說，這至關重要。

但也有人說，垃圾回收及其性能開銷和停頓，使程序在運行時表現得不可預測，並引入了不可接受的延遲。爭論還在繼續。

Go 是一種與 Rust 非常不同的語言。雖然兩者都可以被模糊地描述爲系統語言或 C 語言的替代品，但它們有不同的目標和應用、語言設計的風格以及優先級。垃圾回收是一個真正巨大的區別。Go 中的 GC 使語言更簡單，更小，更容易推理。在 Rust 中沒有 GC 會讓它變得非常快（尤其是當你需要保證延遲，而不僅僅是高吞吐量的時候），並且可以實現 Go 中不可能實現的功能和編程模式（或者至少是在不犧牲性能的情況下）。 - PingCAP[30]

接近機器

計算機編程的歷史是一個越來越複雜的抽象的故事，它讓程序員在解決問題時不用太擔心底層機器的實際運作。

這使得程序更容易編寫，也許更容易移植。但是對於許多程序來說，對硬件的訪問以及對程序執行方式的精確控制更爲重要。

Rust 的目標是讓程序員 “更接近機器”，有更多的控制權，但 Go 抽象了架構細節，讓程序員更接近問題。

兩種語言都有不同的適用範圍。Go 在編寫微服務和典型的 "DevOps" 任務方面表現出色，但它不是一種系統編程語言。Rust 對於那些看重併發性、安全性和性能的任務中更強；但它的學習曲線比 Go 更陡峭。 - Matthias Endler[31]

必須運行更快

許多人同意，對於大多數程序來說，性能不如可讀性重要 [32]。但當性能確實重要時，它真的很重要。Rust 做了一些設計上的權衡，以達到儘可能好的執行速度。

相比之下，Go 更關注簡單性，它願意爲此犧牲一些（運行時）性能。但是 Go 的構建速度是無可匹敵的，這對於大型代碼庫來說是非常重要的。

Rust 比 Go 快。在基準測試中，Rust 更快，在某些情況下，甚至是數量級的快。但在你選擇用 Rust 寫所有東西之前，考慮一下 Go 在許多基準測試中並不落後於它，而且它仍然比 Java、C#、JavaScript、Python 等快得多。如果你需要的是頂級的性能，那麼選擇這兩種語言中的任何一種，你都會在遊戲中領先。如果你正在構建一個處理高負載的網絡服務，你希望能夠在縱向和橫向上進行擴展，那麼這兩種語言都會非常適合你。- 安德魯 - 拉德 [33]

正確性

另一方面，如果一個程序不需要正常工作的話，它可以任意地快。大多數代碼不是爲長期而寫的，但有些程序能在生產中運行多長時間往往是令人驚訝的：在某些情況下，可以保持幾十年。

在這種情況下，值得在開發中多花一點時間，以確保程序的正確性、可靠性，並在未來不需要大量的維護。

Go 和 Rust 都旨在幫助你編寫正確的程序，但方式不同。例如，Go 提供了一個極好的內置測試框架，而 Rust 則專注於使用其借用檢查器消除運行時的錯誤。

我認爲。Go 適用於明天必須交付的代碼，而 Rust 適用於必須在未來五年內保持運行不動的代碼。 - Grzegorz Nosek

雖然 Go 和 Rust 對於任何嚴肅的項目來說都是很好的選擇，但是讓自己儘可能地瞭解每種語言及其特點是一個好主意。

歸根結底，別人怎麼想並不重要：只有你能決定哪種語言適合你和你的團隊。

如果你想加快開發速度，也許是因爲你有許多不同的服務需要編寫，或者你有一個龐大的開發團隊，那麼 Go 是你的首選語言。Go 把併發性作爲第一等公民給你，並且不容忍不安全的內存訪問（Rust 也是如此），但不強迫你管理每一個細節。Go 是快速和強大的，但它避免了使開發者陷入困境，而是專注於簡單性和統一性。如果在另一方面，擰出每一盎司的性能是必要的，那麼 Rust 應該是你的選擇。 - 安德魯 - 拉德 [34]

結論

我希望這篇文章能讓你相信 Rust 和 Go 都值得你認真考慮。如果可能的話，你應該爭取在這兩種語言中至少獲得一定程度的經驗，因爲它們對你的任何技術職業都會有極大的幫助，甚至如果你僅把編程作爲一種業餘愛好的話。

如果你只有時間投資學習一門語言，在你將 Go 和 Rust 用於各種不同類型的大小程序之前，不要做出最終決定。

而編程語言的知識實際上只是成爲一名成功的軟件工程師的一小部分。到目前爲止，你需要的最重要的技能是設計、工程、架構、溝通和協作。如果你在這些方面表現出色，無論你選擇哪種語言，你都會成爲一名優秀的軟件工程師。學習愉快!

Gopher Daily(Gopher 每日新聞) 歸檔倉庫 - https://github.com/bigwhite/gopherdaily

參考資料

[1]

《Rust vs Go in 2023》: https://bitfieldconsulting.com/golang/rust-vs-go

[2]

Go 和 Rust 的道: https://tonybai.com/2022/09/25/the-tao-of-go

[3]

Gints Dreimanis: https://serokell.io/blog/rust-guide

[4]

go.dev: https://go.dev

[5]

正確: https://bitfieldconsulting.com/golang/crisp-code

[6]

高性能: https://bitfieldconsulting.com/golang/slower

[7]

Python: https://bitfieldconsulting.com/golang/go-vs-python

[8]

以函數式編程爲主的語言: https://bitfieldconsulting.com/golang/functional

[9]

Rob Pike: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s

[10]

山姆 - 羅斯: https://samwho.dev/

[11]

更傾向於清晰的代碼而不是快速的代碼: https://bitfieldconsulting.com/golang/slower

[12]

學習 Go 語言: http://gk.link/a/10AVZ

[13]

一個 Rust 程序員對 Go 的早期印象: https://medium.com/better-programming/early-impressions-of-go-from-a-rust-programmer-f4fd1074c410

[14]

代碼俱樂部視頻系列: https://bitfieldconsulting.com/code-club

[15]

簡單、明顯、常規、直接的程序: https://bitfieldconsulting.com/golang/commandments

[16]

馬蒂亞斯 - 恩德勒: https://endler.dev/2017/go-vs-rust/

[17]

devathon: https://devathon.com/blog/rust-vs-go-which-programming-language-to-choose/

[18]

戴夫 - 切尼: https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors

[19]

泛型: https://bitfieldconsulting.com/golang/generics

[20]

Sonya Koptyev: https://sdtimes.com/softwaredev/the-developers-dilemma-choosing-between-go-and-rust/

[21]

rayon 庫: https://github.com/rayon-rs/rayon

[22]

一個 Rust 程序員對 Go 的早期印象: https://medium.com/better-programming/early-impressions-of-go-from-a-rust-programmer-f4fd1074c410

[23]

Dave Cheney: https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors

[24]

爲什麼是 Rust？: https://bitbucket.org/blog/why-rust

[25]

山姆 - 羅斯: https://samwho.dev/

[26]

Matthias Endler: https://endler.dev/2017/go-vs-rust/

[27]

Rob Pike: https://talks.golang.org/2012/splash.article

[28]

Loris Cro: https://kristoff.it/blog/why-go-and-not-rust

[29]

Go 的整個編程方法: https://tonybai.com/2022/09/25/the-tao-of-go

[30]

PingCAP: https://medium.com/better-programming/early-impressions-of-go-from-a-rust-programmer-f4fd1074c410

[31]

Matthias Endler: https://endler.dev/2017/go-vs-rust/

[32]

性能不如可讀性重要: https://bitfieldconsulting.com/golang/slower

[33]

安德魯 - 拉德: https://codeburst.io/should-i-rust-or-should-i-go-59a298e00ea9

[34]