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

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

1，C語言：迷人的陷阱

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

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

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

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

2，安全問題

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

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

3，Elixir：不合格的繼承人

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

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

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

4，Rust

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

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

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

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

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

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

5，值得期待的未來

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

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

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