一時之間，Rust 編程語言陷入到了接連被棄用的窘境。

作為一門系統編程語言，Rust 專注于安全，尤其是并發安全。它支持函數式和命令式以及泛型等編程范式的多范式語言，在語法上和 C、C++ 類似。

圖源：https://x.com/ThePrimeagen/status/1875592777440084416

就在剛剛過去的 12 月底，知名開源項目 curl 的創始人 Daniel Stenberg 宣布：將放棄支持基于 Rust 編寫的 Hyper HTTP 后端，并徹底移除相關代碼。此舉引起了開發者社區的廣泛關注。

旅程即將結束，實驗結束了。我們努力過，但還是失敗了。

2020 年，Stenberg 開始在 curl 中添加對另一種 HTTP 后端的支持，它使用了基于 Rust 編寫的庫，被稱為 hyper。他的想法是引入一種替代的 HTTP 內部實現，從而可以讓 curl/libcurl 使用它來代替本機實現。目標是借助 Rust 的內存安全性，為 curl 用戶提供一個更安全的 HTTP 后端實現。

最初的工作得到了 ISRG 的慷慨贊助，它是「Let’s Encrypt」等出色工作的背后組織。期間 Stenberg 與 hyper 首席開發人員 Sean McArthur 密切合作，并取得了很大進展。到目前為止，Stenberg 已經在 curl 中以 EXPERIMENTAL 為標簽提供了 hyper 支持，希望吸引用戶的興趣并激發他們的實驗精神。

Stenberg 表示，他們已經完成了 95% 的工作，而且幾乎整個測試套件都以相同的方式運行，無論構建 curl 時使用哪個后端。然而，正是那最后的百分之幾卻變成了最大的阻力，最終導致了項目失敗、放棄并全部撤出。

為什么呢？總結起來，主要有以下兩方面原因。

一方面，幾乎沒人有這樣的需求，curl 的用戶對 hyper 沒有興趣；現有的 hyper 用戶也不關心它是否兼容 curl。

另一方面，libcurl 庫是用 C 編寫的，hyper 是用 rust 編寫的，兩者之間需要一個 C 粘合層。這就需要同時精通 C 和 Rust 語言的開發者來深入研究相關的架構和協議，來推動項目進展。現實卻是缺乏這樣的開發者。

因此，由于預計無法在短中期內完成 hpyer 工作，并且保留代碼的成本實在太高，只能通過削減這些代碼來提供靈活性并降低復雜性。

雖然 hyper 的實驗本身失敗了，Stenberg 認為他們從中吸取了一些教訓，并在過程中改進了 curl。其實在 2020 年開始 hyper 項目的時候，Rust 語言本身并沒有準備好。隨著時間的推移，Rust 現在已經有所改進，成為一種更好的語言，并可以為類似 hyper 的項目提供更好的服務。

另外，在拋棄 hyper 之后，curl 仍然有兩個 Rust 編寫的實驗性后端支持，分別是 rustls（用于 TLS）和 uiche（用于 QUIC 和 HTTP/3）。這兩個后端在 crul 中使用了更好的內部 API，并以更干凈的方式掛接到 libcurl 中，因而相較于 hyper 更易于支持，負擔也更小。

目前，hyper 的超級后端代碼已從 git 中刪除，并且 2025 年 2 月發布的 curl 8.12.0 版本中將不會留下任何痕跡。

不過，雖然 hpyer 被移除了，Stenberg 對未來引入 Rust 或其他語言編寫的安全后端持開放態度。未來會采用一些不一樣的做法，畢竟與 2020 年開始 hyper 時相比，他們現在擁有了更好的內部架構。

無獨有偶，在 12 月初，另一個開源數據庫工具鏈項目 Prisma 也表態將從 Rust 遷移至 TypeScript，以追求更好的插件和擴展生態。

聲明中寫道：Prisma 的架構歷來限制社區貢獻，其核心功能（例如查詢解析、驗證和執行）由 Rust 引擎管理，而這對于專注于 TypeScript 的社區來說是不透明的。因此決定將 Prisma 的核心邏輯從 Rust 遷移到 TypeScript，并重新設計 ORM，以使定制和擴展更容易。

近幾年 Rust 語言正在強勢崛起，在一些編程語言排行榜中的排名一直在攀升，比如 2024 IEEE Top 編程語言榜單中，Rust 的排名就很靠前。另外，用 Rust 取代 C 和 C++ 的呼聲也很高。

雖然 Rust 很強大且在安全性方面獨樹一幟，但它的學習成本也相對比較高。在一個關于「哪些原因阻止你在 2025 年學習 Rust」的調查中，有人拋出了一個有力的觀點：他最常用的 C/C++ 庫是同類中最好的，背后有數十年的開發經驗。對于 Rust，他要么費盡心力地繼續使用它，要么使用一些隨機、不知名、沒有血統的包。也有人認為，Rust 語法看起來很丑陋。

圖源：https://x.com/kai_fall/status/1875549570513658212

用了 18 個月，我滿滿的都是后悔

其實，在 2024 年初，Medium 一篇文章講述了作者花費了 18 月用 Rust 語言重建自己的算法交易平臺的過程。雖然費了很多心思，但最終十分后悔。一起看看在這過程中，Austin Starks 到底經歷了什么吧。

在文章開頭 Austin 就表示了他曾經十分看好 Rust，甚至是 Rust 的狂熱愛好者。Rust 看起來似乎是目前最快的、最安全編程語言之一。當然他發現不止自己一人這么認為。如果在網上閱讀有關 Rust 編程語言的文章，你很可能會遇到壓倒性的正面評價。每一篇 Medium 上的指南、每一篇 Reddit 上的帖子、每一個 Stack Overflow 上的回答 —— 一切都在贊美它。

這是故事的開始，或者說是「噩夢」的開始，Austin 決定放棄 TypeScript，將自己的整個開源算法交易系統重寫成 Rust。

其實，這次不好的體驗早有端倪。更早前，Austin 就寫過一篇關于使用 Rust 的經歷。他當時表示雖然非常喜歡 Rust 的速度和一些語言設計，但并不完全真正喜歡這門語言。不過文章一經發出，就遭到了猛烈的抨擊。甚至有一條高贊評論指責 Austin 是用 ChatGPT 寫的文章。這顯然已經是 AI 時代人們對文字創作最大的批評了。

Austin 進行了反思，或許是自己沒有給予 Rust 足夠的機會。他決定再使用一段時間 Rust。使用過后，他終于能夠自信地給出結論：

這門語言就是糟透了！！！

Rust 差在哪里？

Austin 用了幾個詞來形容來總結自己對 Rust 的厭惡：糟糕、冗長、難以理解的語法和語義。

 一個復雜的 Rust 函數示例

Austin 吐槽道，說 Rust 語義不糟糕的人都是在撒謊。如果沒有一個非常強大的大型語言模型，在寫函數的時候就會有很多事情做不成。他不想花 90 分鐘去弄清楚 run_transaction 函數中的 where 子句。最終，他完全放棄了使用輔助函數的想法，因為根本無法讓代碼編譯通過。人們所說的 Rust 最大的優點（嚴格的編譯器來消除錯誤）反而是 Rust 最大的缺點。

Austin 舉了個例子，如果在 Go 中編寫這個完全相同的函數，代碼大概會下圖這樣。雖然函數的核心結構保持相對不變， 但代碼能直接按照預期運行，不需要做過多復雜的調整、技巧或反復的嘗試。 

 Go 實現的函數 

Rust 在錯誤處理方面似乎有些優勢。只要你避免使用不安全的 unwrap 來減少運行時錯誤（例如空指針異常），就可以確定代碼會運行并持續運行。真的是這樣嗎？Austin：不！

他指出當數據出錯或發生意外時，開發者很難快速診斷問題，因為錯誤信息往往不夠直觀，開發者可能很難弄明白錯誤的根本原因。他自嘲，可能自己沒有找到啟用堆棧跟蹤的正確方法，這讓調試變得更加困難。

Austin：我的堆棧跟蹤在哪兒？？？ 

相比之下，Python 能夠提供堆棧跟蹤，精確告訴你發生了什么，甚至到行號。Austin 表示，就算是 Go 語言，也有 errors.Wrap (...)，讓你能夠查看整個錯誤堆棧。顯然，這是 Rust 的設計缺陷。

除了 Rust 的設計缺陷，社區氛圍也是難評。Austin 表示，社區不能接受別人提出 Rust 有缺陷這個觀點。發表的看法會遭到攻擊，提出的問題也只能收獲陰陽怪氣。

Austin 在 Rust 社區中收到的「有用」回復