前言
我知道 Rust 或許很熱門，但一名叫 Chad (Robert Swellington) 的作者認為 C++ 更能助你成功。我個人 C++ 的經驗主要停留在 C++ 11，因為編譯器限制。希望 Modules 最終能真正實現。
願榮耀歸於貧窮的螃蟹
程式語言是工具，而非宗教
宗教與程式語言的關聯
程式語言應視為工具，而非宗教信仰。 「宗教」(religion) 一詞源自法語 "relig"，再追溯至拉丁語 "religare"，意指「緊抓」。 這個詞彙讓人聯想到在波濤洶湧的大海上緊抓繩索的水手。 程式語言是否也如同在逆境中緊抓的繩索？
Rust 的優點與缺點
Rust 確實有其優點，例如內存安全，無需垃圾回收。 然而，要推出實際可上市的產品，C++ 和 C# 等語言更勝一籌。
Borrow Checker 的雙面刃
Borrow Checker 的限制
Rust 以 Borrow Checker 聞名，它就像一個過度謹慎的朋友，阻止你爬樹，因為你可能會摔斷腿。 它本應透過強制執行嚴格規則來避免常見的缺陷，但在實踐中，你經常需要與之搏鬥才能讓程式碼編譯成功。 每花一分鐘與之搏鬥，就少了一分鐘可用於開發功能、修復其他錯誤或從事任何其他有生產力的工作。
Rust 的安全性與表達能力
Rust 的核心概念是，所有安全的程式都應該被 Rust 允許。 當你設計的程式在邏輯上是安全的，但無法用 Rust 語言表達時，就會與編譯器產生衝突。 許多人對 Rust 的不滿，並非來自於不想編寫安全程式，而是他們的程式雖然安全，卻無法用 Rust 表達。
克服 Borrow Checker 的挑戰
如果你正在與 Borrow Checker 搏鬥，不代表你不懂 Rust。 即使是有經驗的 Rust 開發者，在處理大型專案時，也會遇到 Borrow Checker 的挑戰。 解決方案是採用 "Rust 式" 的編寫方式，但這種方式通常需要透過大量實踐才能掌握。 重構 Rust 程式碼可能非常困難。
完美主義與進度
Rust 似乎要求開發者從一開始就編寫完美的程式碼。 這在理論上聽起來不錯，但如果身處新創環境或快節奏的開發週期中，需要快速推出產品以驗證其價值，那該怎麼辦？ 花費大量時間與 Borrow Checker 搏鬥以產生完美的程式碼，可能會浪費寶貴的時間，而這些時間本可以用於測試產品在市場上的反應。
快速開發與 MVP
MVP 的語言選擇
對於 MVP（最小可行產品），可以使用任何你最熟悉的語言。 如果你只關心推出產品，那就選擇你最擅長的語言。
時間與金錢
老闆不在乎零成本抽象的理論優勢。 如果使用 Rust 等語言導致產品上市時間加倍，那就不值得。 使用 C++ 和 C，可以減少與語言的搏鬥，將更多時間用於編寫程式碼，創造實際價值。
生態系統與支援
C++ 和 C 的優勢
C++ 和 C 擁有龐大的用戶群體、豐富的函式庫和大量的線上資源。 如果遇到問題，很可能已經有人遇到並解決了，只需快速搜尋即可找到答案。 Rust 正在迎頭趕上，但尚未達到相同的水平。
實用性
企業關心的是能夠運作的解決方案。 C++ 和 C 在遊戲開發、後端和嵌入式系統等多個領域都有長期成功的記錄。 Rust 或許有一天會趕上，但目前來說風險較高。
Garbage Collection 與生產力
垃圾回收 (Garbage Collection) 在 C# 等語言中可能被系統程式設計師鄙視，但它能讓你快速開發。 即使對 C# 不夠熟悉，也能快速編寫程式。 在商業世界中，速度通常勝過完美。 在非關鍵路徑上出現微小的內存洩漏，可以用更快的產品上市時間來彌補。
結論：選擇適合你的工具
如果目標是追求速度，那麼選擇你最熟悉的語言。 如果你不確定該選擇哪種語言，Go 是一個容易入門的選擇。 雖然 Go 可能不是最令人興奮的語言，但它非常簡單且高效。 然而，Go 的標準函式庫並不完善，缺乏一些複雜性。
對於 C++ 的補充說明
C++ 雖然功能強大，但也非常複雜。 掌握 C++ 需要大量的學習和實踐。
{# 
{#