在過去的一段時間里，“用Rust重寫”的趨勢席卷了整個開發(fā)領(lǐng)域。作為一顆冉冉升起的新星，Rust不僅承諾更好的內(nèi)存安全性和更高的技術(shù)穩(wěn)定性，還可以兼顧開發(fā)和執(zhí)行效率。這也使得越來越多的系統(tǒng)開發(fā)人員轉(zhuǎn)向這種面向未來的編程語言。

就在最近，另一個知名的開源項目Ockam放棄了系統(tǒng)中數(shù)萬行C語言代碼，最終用Rust重寫了整個項目。在完成這個龐大的項目后，Ockam的創(chuàng)始人Mrinal Wadhwa分享了他帶領(lǐng)團隊從C到Rust的歷程。

1，C語言：迷人的陷阱

作為一個開源的開發(fā)者工具，Ockam在GitHub上有3.3萬顆星。其核心功能是幫助用戶構(gòu)建可信的動態(tài)數(shù)據(jù)，并為用戶應(yīng)用程序添加端到端加密和認證通信；確保應(yīng)用程序具有端到端的數(shù)據(jù)完整性、真實性和機密性。

研發(fā)團隊希望Ockam可以在任何環(huán)境中運行，包括受限的邊緣設(shè)備或強大的云服務(wù)器。除此之外，Ockam的另一個目標是可以在任何類型的應(yīng)用程序中使用，而不管應(yīng)用程序是用什么語言構(gòu)建的。

這樣的需求使得C語言成為構(gòu)建Ockam項目的候選語言——它可以為大多數(shù)設(shè)備編譯，并且所有流行的語言都可以通過某種形式的接口調(diào)用C庫。在這種情況下，Ockam能夠為所有其他語言提供慣用的包裝器。

該團隊的想法是將以通信為中心的核心協(xié)議從硬件行為中分離出來，并為它想要支持的硬件提供可插拔的適配器?？紤]到這個想法，開發(fā)人員在初始版本中將Ockam項目的核心實現(xiàn)為C庫，并用其他語言包裝器包裝該庫。

2，安全問題

然而，盡管基于Ockam內(nèi)核實現(xiàn)的C庫滿足了項目到處運行的需求，但由于C語言內(nèi)存管理的弱點，團隊實現(xiàn)的C庫中許多與加密相關(guān)的代碼容易出現(xiàn)漏洞，一個小錯誤就可能導(dǎo)致系統(tǒng)變得不安全。

這與Ockam項目的目標完全相反，Ockam項目的目標是隱藏這些問題，并提供一個易于正確使用的開發(fā)人員界面。該團隊開始嘗試使用C語言構(gòu)建安全簡單的接口。但經(jīng)過多次迭代，開發(fā)人員逐漸發(fā)現(xiàn)，他們必須掌握大量關(guān)于協(xié)議狀態(tài)和狀態(tài)轉(zhuǎn)換的細節(jié)，即使他們非常小心，代碼中也總會存在無法檢測到的漏洞。

3，Elixir：不合格的繼承人

面對極其痛苦的迭代工作，仍然無法解決內(nèi)存安全問題的Ockam決定放棄C語言，尋找更適合這個項目的繼任者——當(dāng)時，他們把目光投向了基于erlang的Elixir語言。

Elixir程序在提供Erlang進程的Erlang虛擬機BEAM上運行。Erlang進程是輕量級的有狀態(tài)并發(fā)參與者。由于參與者可以在保持內(nèi)部狀態(tài)的同時并發(fā)運行，因此很容易運行并發(fā)狀態(tài)協(xié)議棧：Ockam傳輸 + Ockam路由 + Ockam安全通道。

但不幸的是，Elixir天生就是為支持高負載項目而設(shè)計的，不能像C語言那樣在小型或受限的計算機上運行。此外，Elixir的生態(tài)還不夠成熟，對于某些特定的語言管理包裝器來說不是一個好的選擇。

4，Rust

在經(jīng)歷了連續(xù)的失敗之后，Ockam團隊意識到他們的核心需求是在確保安全性的同時實現(xiàn)輕量級參與者，但是C語言和Elixir都無法完美地適應(yīng)。從此，Wadhwa開始帶領(lǐng)團隊研究Rust，并很快發(fā)現(xiàn)了這門語言的獨特魅力。

Rust庫能夠?qū)С雠cC調(diào)用兼容的接口。這意味著任何靜態(tài)/動態(tài)鏈接或從C庫調(diào)用函數(shù)的語言都能夠以完全相同的方式從Rust庫調(diào)用函數(shù)。由于大多數(shù)語言都支持C中的本機函數(shù)，因此它們也支持Rust中的本機函數(shù)。從包裝器的角度來看，Rust和C之間幾乎沒有區(qū)別。

Rust的內(nèi)存安全特性消除了use-after-free、double-free、溢出、越界訪問和許多其他常見錯誤的可能性。根據(jù)之前的調(diào)查，這些錯誤導(dǎo)致了C或C++庫中60-70%的關(guān)鍵漏洞。Rust在編譯時提供了這種安全性，這使得它在編寫需要高性能、在受限環(huán)境中運行和高度安全的代碼時具有很大的優(yōu)勢。

研發(fā)團隊堅信Rust和Ockam是天作之合的最后一個原因是Rust中的async/await。Ockam需要輕量級參與者來創(chuàng)建簡單而安全的協(xié)議棧接口。async/await意味著在tokio和async-std等項目中已經(jīng)完成了許多創(chuàng)建actor的工作，團隊可以在此基礎(chǔ)上輕松構(gòu)建Ockam的actor實現(xiàn)。

基于rust的async/await無論在大型機還是微型計算機上運行，都可以向用戶提供完全相同的界面，位于Ockam Workers上的協(xié)議接口也可以呈現(xiàn)完全相同的簡單接口。

最終，在Wadhwa的帶領(lǐng)下，Ockam放棄了系統(tǒng)中數(shù)萬行C語言代碼，用一段時間完成了對Rust的全面改造。經(jīng)過重寫后穩(wěn)定性的多次迭代，任何用戶現(xiàn)在都可以使用重新激活的Ockam包，通過簡單的函數(shù)調(diào)用，在任何設(shè)備上創(chuàng)建他們想要的端到端加密和相互認證的安全通道。

5，值得期待的未來

Ockam的故事實際上只是一個縮影。對于今天被內(nèi)存安全問題困擾的絕大多數(shù)項目來說，使用Rust或基于Rust的重構(gòu)不再是一個實驗或賭注，而是一個足夠?qū)嵱煤涂煽康慕鉀Q方案。

在Ockam之前，微軟在4月份宣布，出于內(nèi)存安全考慮，它將使用18萬行Rust代碼重寫核心Windows庫；Armin是Python web框架Flask的作者，他在一篇關(guān)于Python 2023發(fā)展趨勢的文章中也提出了將Rust集成到Python項目和工具中的想法；Ruff的創(chuàng)始人在成立新公司時，也曾宣稱未來將通過Rust徹底改變Python生態(tài)系統(tǒng)。

更令人欣慰的是，Rust的進化還在繼續(xù)。根據(jù)其發(fā)布的Rust 2024路線圖，官方團隊將在未來繼續(xù)努力，降低學(xué)習(xí)門檻，加強生態(tài)連接。幫助Rust盡快擺脫飽受詬病的“高門檻”標簽，讓它盡快在更多場景中發(fā)揮價值。在這方面，Rust的未來確實值得我們每個人的期待。