接連被開源專案curl、Prisma棄用，Rust語言遭遇水逆，網友：從狂熱粉到後悔莫及
机器之心發表於2025-01-05
一時之間，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其實，在 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。使用過後，他終於能夠自信地給出結論：Austin 用了幾個詞來形容來總結自己對 Rust 的厭惡：糟糕、冗長、難以理解的語法和語義。Austin 吐槽道，說 Rust 語義不糟糕的人都是在撒謊。如果沒有一個非常強大的大型語言模型，在寫函式的時候就會有很多事情做不成。他不想花 90 分鐘去弄清楚 run_transaction 函式中的 where 子句。最終，他完全放棄了使用輔助函式的想法，因為根本無法讓程式碼編譯透過。人們所說的 Rust 最大的優點（嚴格的編譯器來消除錯誤）反而是 Rust 最大的缺點。Austin 舉了個例子，如果在 Go 中編寫這個完全相同的函式，程式碼大概會下圖這樣。雖然函式的核心結構保持相對不變， 但程式碼能直接按照預期執行，不需要做過多複雜的調整、技巧或反覆的嘗試。 Rust 在錯誤處理方面似乎有些優勢。只要你避免使用不安全的 unwrap 來減少執行時錯誤（例如空指標異常），就可以確定程式碼會執行並持續執行。真的是這樣嗎？Austin：不！他指出當資料出錯或發生意外時，開發者很難快速診斷問題，因為錯誤資訊往往不夠直觀，開發者可能很難弄明白錯誤的根本原因。他自嘲，可能自己沒有找到啟用堆疊跟蹤的正確方法，這讓除錯變得更加困難。相比之下，Python 能夠提供堆疊跟蹤，精確告訴你發生了什麼，甚至到行號。Austin 表示，就算是 Go 語言，也有 errors.Wrap (...)，讓你能夠檢視整個錯誤堆疊。顯然，這是 Rust 的設計缺陷。除了 Rust 的設計缺陷，社群氛圍也是難評。Austin 表示，社群不能接受別人提出 Rust 有缺陷這個觀點。發表的看法會遭到攻擊，提出的問題也只能收穫陰陽怪氣。 Austin 在 Rust 社群中收到的「有用」回覆你有用過 Rust 嗎？在評論區分享一下你的體驗吧。擴充閱讀：半小時入門 Rust，這是一篇 Rust 程式碼風暴https://www.prisma.io/blog/prisma-orm-manifestohttps://daniel.haxx.se/blog/2024/12/21/dropping-hyper/https://spectrum.ieee.org/top-programming-languages-2024https://medium.com/codex/i-spent-18-months-rebuilding-my-algorithmic-trading-in-rust-im-filled-with-regret-d300dcc147e0