在新創公司使用 Rust：一個警世故事
source : https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautionary-tale-42ab823d9454 by 馬特威爾士
對於某些事情來說，Rust 非常棒。但對於需要快速發展的新創公司來說，在選擇它之前要三思。
這篇文章的所有藝術作品都是使用 DALL-E 生成的。
我猶豫是否要寫這篇文章，因為我不想開始或捲入一場關於程式語言的聖戰。 （只是為了擺脫火焰誘餌，Visual Basic 是有史以來最好的語言！）但有很多人問我有關 Rust 的經驗以及他們是否應該為他們的專案選擇 Rust。因此，我想分享一些我所看到的在新創公司中使用 Rust 的優點和缺點，在新創公司中，快速移動和擴展團隊非常重要。
我想澄清的是，在某些方面我是 Rust 的粉絲。這篇文章並不是關於 Rust 作為一種語言或類似語言有多糟糕。然而，我確實想談談的是，使用 Rust 幾乎肯定會對生產力造成重大影響，如果你想快速行動，這可能是一個主要因素。仔細權衡速度影響是否值得該語言為您的公司和產品帶來的好處。
首先，我應該說Rust 非常擅長它的設計目的，如果您的專案需要 Rust 的特定優勢（一種具有高效能、超強類型、不需要垃圾收集等的系統語言）那麼 Rust 是一個不錯的選擇。但我認為 Rust 通常用在不太適合的情況下，團隊付出了 Rust 的複雜性和開銷的代價，卻沒有得到太多好處。
我對 Rust 的主要經驗來自於在之前的一家新創公司使用它兩年多的時間。這個專案是一個基於雲端的 SaaS 產品，或多或少是一個傳統的 CRUD 應用程式：它是一組微服務，在資料庫前面提供 REST 和 gRPC API 端點，以及一些其他後台。是用Rust 和Python 組合實現的）。使用 Rust 主要是因為該公司的幾位創辦人都是 Rust 專家。隨著時間的推移，我們的團隊規模不斷擴大（工程人員數量增加了近 10 倍），程式碼庫的規模和複雜性也大幅成長。
隨著團隊和程式碼庫的成長，我覺得隨著時間的推移，我們為繼續使用 Rust 付出了越來越重的稅。開發有時很緩慢，推出新功能的時間比我預期的要長，團隊感受到了使用 Rust 的早期決定對生產力的真正影響。從長遠來看，用另一種語言重寫程式碼將使開發更加靈活並加快交付時間，但找到時間進行主要重寫工作將非常困難。所以我們有點被 Rust 困住了，除非我們決定硬著頭皮重寫大量程式碼。
生鏽應該是自切片麵包以來最好的東西，那麼為什麼它對我們來說效果不佳呢？
Rust 有一個巨大的學習曲線。
我在職業生涯中使用過數十種語言，除了少數例外，大多數現代過程語言（C++、Go、Python、Java 等）在基本概念方面都非常相似。每種語言都有其差異，但通常只需學習一些不同語言之間不同的關鍵模式，然後就可以快速提高工作效率。然而，對於 Rust，人們需要學習全新的想法 — — 諸如生命週期、所有權和借用檢查器之類的東西。對於大多數使用其他通用語言工作的人來說，這些概念並不熟悉，而且即使對於經驗豐富的程式設計師來說，學習曲線也相當陡峭。
當然，其中一些「新」想法也存在於其他語言中 — — 尤其是函數式語言 — — 但 Rust 將它們帶入了「主流」語言環境，因此對於許多 Rust 新手來說將是新鮮的。
儘管是與我共事過的一些最聰明、最有經驗的開發人員，但團隊中的許多人（包括我自己）都很難理解在Rust 中執行某些操作的規範方法，如何理解來自編譯器的經常晦澀難懂的錯誤訊息，或如何理解關鍵庫的工作原理（更多內容請見下文）。我們開始每週為團隊舉辦「學習 Rust」課程，以幫助分享知識和專業知識。這極大地消耗了團隊的生產力和士氣，因為每個人都感到開發速度緩慢。
作為軟體團隊採用新語言的比較，我在 Google 的一個團隊是最早從 C++ 完全切換到 Go 的團隊之一，整個過程只花了不到兩週的時間。地使用Go 進行編碼。對於 Rust，即使每天使用該語言工作數月之後，團隊中的大多數人也從未感到自己完全有能力。許多開發人員告訴我，他們常常感到尷尬，因為他們的功能落地所需的時間比他們預期的要長，而且他們花了很長時間試圖理解 Rust。
還有其他方法可以解決 Rust 試圖解決的問題。
如上所述，我們正在建立的服務是一個相當簡單的 CRUD 應用程式。在這個特定係統的生命週期中，該服務的預期負載將不會超過每秒最多幾個查詢。該服務是一個相當複雜的資料處理管道的前端，可能需要幾個小時才能運行，因此服務本身預計不會成為效能瓶頸。沒有特別擔心像 Python 這樣的傳統語言會在提供良好效能方面遇到任何困難。除了任何面向網路的服務需要處理的之外，沒有特殊的安全或並發需求。我們使用 Rust 的唯一原因是因為該系統的原始作者是 Rust 專家，而不是因為它特別適合建立此類服務。
Rust 做出了安全比開發人員生產力更重要的決定。在許多情況下，這是正確的權衡 — — 例如在作業系統核心中建立程式碼，或者對於記憶體受限的嵌入式系統 — — 但我不認為這在所有情況下都是正確的權衡，尤其是在速度至關重要的新創公司中。我是一個實用主義者。我寧願讓我的團隊花時間調試用Python 或Go 等編寫的程式碼偶爾出現的記憶體洩漏或類型錯誤，也不願讓團隊中的每個人因為使用旨在完全避免這些問題的語言而遭受4 倍的生產力打擊。
正如我上面提到的，我在 Google 的團隊完全用 Go 建立了一項服務，隨著時間的推移，該服務逐漸支援超過 8 億用戶，而 QPS 是 Google 搜尋高峰期的 4 倍。在建造和運行這項服務的這些年裡，我一隻手就能數出我們遇到由 Go 的類型系統或垃圾收集器引起的問題的次數。基本上，Rust 旨在避免的問題可以透過其他方式解決- 透過良好的測試、良好的 linting、良好的程式碼審查和良好的監控。當然，並不是所有的軟體專案都有這種奢侈，所以我可以想像 Rust 在其他情況下可能是個不錯的選擇。
你將很難僱用 Rust 開發人員。
我在這家公司工作期間僱用了很多人，但加入工程團隊的 60 多人中只有大約兩到三人有 Rust 經驗。這並不是因為想要尋找 Rust 開發者 — — 他們只是不在那裡。 （出於同樣的原因，我們對僱用只想用 Rust 進行編碼的人猶豫不決，因為我認為在需要以敏捷方式做出語言和其他技術選擇的初創公司環境中這是一個不好的期望。 ） Rust 開發人才的數量會隨著時間的推移而變化，因為 Rust 變得更加主流，但圍繞 Rust 構建的假設是你將能夠僱用已經知道它的人似乎有風險。
另一個次要因素是，使用 Rust 幾乎肯定會導致團隊中了解 Rust 的人和不了解 Rust 的人之間的分裂。因為我們為這項服務選擇了一種「深奧」的程式語言，所以公司中的其他工程師在構建功能、調試生產問題等方面可能會有所幫助，但他們在很大程度上無法提供幫助，因為他們無法思考或思考。當您試圖快速行動並利用團隊中每個人的綜合優勢時，工程團隊缺乏可替代性可能會成為真正的負擔。根據我的經驗，人們在 C++ 和 Python 等語言之間遷移通常沒有什麼困難，但 Rust 足夠新，也足夠複雜，它給人們一起工作帶來了障礙。
圖書館和文件還不成熟。
這個問題（我希望！）會隨著時間的推移而解決，但與 Go 相比，Rust 的庫和文件生態系統非常不成熟。現在，Go 的好處是，在向全世界發布之前，它是由 Google 的整個專業團隊開發和支援的，因此文件和程式庫都相當完善。相比之下，Rust 長期以來一直讓人感覺像是一項正在進行中的工作。許多流行庫的文檔非常稀疏，人們通常需要閱讀給定庫的源代碼才能了解如何使用它。這不好。
團隊中的 Rust 辯護者經常會說「async/await 仍然很新」和「是的，缺少該庫的文檔」之類的話，但這些缺點對團隊影響相當大。我們很早就犯了一個巨大的錯誤，採用Actix 作為我們服務的Web 框架，這個決定給我們帶來了巨大的痛苦和痛苦，因為我們遇到了深藏在庫中的錯誤和問題，沒有人知道如何修復。 （公平地說，這是幾年前的事了，也許現在情況已經有所改善。）
當然，這種不成熟並不是 Rust 特有的，但它確實相當於你的團隊必須繳納的稅。無論核心語言文件和教程有多出色，如果您不知道如何使用這些庫，那也沒有多大關係（當然，除非您打算從頭開始編寫所有內容）。
Rust 讓開發新功能變得非常困難。
我不了解其他人，但至少對我來說，當我建立一個新功能時，我通常不會預先確定所有資料類型、API 和其他細節。我經常只是拋出程式碼，試圖讓一些基本想法發揮作用，並檢查我對事情應該如何運作的假設是否或多或少正確。例如，在 Python 中執行此操作非常簡單，因為您可以快速輕鬆地進行打字之類的操作，而不必擔心在您提出想法時某些程式碼路徑是否被破壞。您可以稍後返回並整理所有內容並修復所有類型錯誤並編寫所有測試。
在 Rust 中，這種「草稿編碼」非常困難，因為編譯器可以並且會抱怨每一個沒有通過類型和生命週期檢查的該死的事情 — — 正如它明確設計的那樣。當您需要建立最終的、可用於生產的實作時，這非常有意義，但當您試圖將某些東西拼湊在一起以測試想法或奠定基礎時，這絕對很糟糕。該unimplemented!巨集在一定程度上很有幫助，但仍要求在編譯之前對堆疊中的所有內容進行類型檢查。
真正令人痛苦的是，當您需要更改承載介面的類型簽名，並發現自己花費數小時更改使用該類型的每個地方，只是為了看看您最初的嘗試是否可行。然後當您意識到需要再次更改時重做所有這些工作。
Rust 擅長什麼？
Rust 確實有一些我喜歡的地方，以及我希望在其他語言中擁有的 Rust 功能。語法match很棒。Option、Result、 和特性Error非常強大，?運算子是處理錯誤的優雅方式。其中許多想法在其他語言中都有對應的內容，但 Rust 處理它們的方法特別優雅。
對於需要高水準效能和安全性的項目，我絕對會使用 Rust，我並不非常擔心需要與快速成長的整個團隊一起快速發展程式碼的主要部分。對於單一專案或非常小的（例如 2–3 人）團隊，Rust 可能就足夠了。對於內核模組、韌體、遊戲引擎等性能和安全性至關重要的事物，以及在發貨前可能很難進行真正徹底的測試的情況，Rust 是一個不錯的選擇。
好吧，既然我已經惹惱了一半的《駭客新聞》讀者，我想現在正是宣布我下一篇文章主題的最佳時機：為什麼nano是卓越的文本編輯器。下次見！
