聲明:本文來自微信公眾號“機器之心”（ID:almosthuman2014），作者:杜偉授權站長之家轉載發(fā)布。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rust 差在哪里?

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

一個復雜的 Rust 函數(shù)示例

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

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

Go 實現(xiàn)的函數(shù)

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

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

Austin:我的堆棧跟蹤在哪兒???

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

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

Austin 在 Rust 社區(qū)中收到的「有用」回復

你有用過 Rust 嗎?在評論區(qū)分享一下你的體驗吧。

拓展閱讀:半小時入門 Rust，這是一篇 Rust 代碼風暴

參考鏈接:

https://www.prisma.io/blog/prisma-orm-manifesto

https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/

https://spectrum.ieee.org/top-programming-languages-2024

https://medium.com/codex/i-spent-18-months-rebuilding-my-algorithmic-trading-in-rust-im-filled-with-regret-d300dcc147e0

（舉報）