科技

接連被開源項目curl、Prisma棄用，Rust語言遭遇水逆，網民：從狂熱粉到後悔莫及

01月05日 12:20 新浪網 tech-auto-hilite

機器之心報導

編輯：杜偉、大盤雞

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

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

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

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

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

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

最初的工作得到了 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 和 H湯臣P/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 中編寫這個完全相同的函數，代碼大概會下圖這樣。雖然函數的核心結構保持相對不變，但代碼能直接按照預期運行，不需要做過多複雜的調整、技巧或反復的嘗試。