編譯 | 徐杰承
在過去的一段時間里，“用Rust重寫”的潮流席卷了整個開發(fā)領(lǐng)域。作一顆正在冉冉升起的新星，Rust不僅承諾了更好的內(nèi)存安全保障、更高的技術(shù)穩(wěn)定性，還能夠兼顧開發(fā)與執(zhí)行效率。這也讓越來越多的系統(tǒng)開發(fā)者開始轉(zhuǎn)向這門面向未來的編程語言。
這不，就在最近，又一款知名開源項目Ockam放棄了系統(tǒng)內(nèi)數(shù)萬行的C語言代碼，并最終用Rust實現(xiàn)了對整個項目的重寫。在完成這項龐大的工程后，Ockam的創(chuàng)始人Mrinal Wadhwa也在一篇博客中分享了自己帶領(lǐng)團隊從C轉(zhuǎn)向Rust的心路歷程。
圖片
1、C語言：迷人的陷阱
作為一款開源開發(fā)者工具，Ockam在GitHub上擁有3.3k Stars，其核心功能是幫助用戶構(gòu)建可信的動態(tài)數(shù)據(jù)，為用戶的應用添加端到端的加密和認證通信；保障應用能夠獲得端到端的數(shù)據(jù)完整性、真實性和機密性。
研發(fā)團隊希望Ockam能夠在任何環(huán)境中運行，包括受約束的邊緣設(shè)備或是強大的云服務器。除此之外，Ockam的另一個目標則是可以在任何類型的應用程序中使用，無論應用程序使用什么語言構(gòu)建。
這樣的訴求使得C語言成為了一個構(gòu)建Ockam項目的明顯候選者——它能夠被絕大多數(shù)設(shè)備編譯，并且所有流行語言都可以通過某種形式的接口調(diào)用C庫。在這樣的情況下，Ockam能夠為所有其他語言提供慣用的包裝器。
團隊的想法是將以通信為中心的協(xié)議核心從硬件行為中分離，并為想要支持的硬件提供可插拔的適配器。在這樣的思路下，研發(fā)人員在最初的版本中將項目的Ockam的核心實現(xiàn)為了一個C庫，并用其他語言包裝器對庫進行了包裝。
2、一觸即潰的安全問題
然而基于Ockam核心所實現(xiàn)的C庫雖然滿足了項目四處運行的需求，但由于C語言內(nèi)存管理的薄弱，團隊所實現(xiàn)的C庫中許多與加密相關(guān)的代碼容易存在漏洞，一個微小的失誤就會導致系統(tǒng)變得不安全。
這與Ockam項目的目標簡直背道而馳，為了將這些問題隱藏起來，并提供易于正確使用的開發(fā)者界面。團隊開始嘗試使用C語言構(gòu)建安全簡單的接口。但在多次迭代中，開發(fā)人員漸漸發(fā)現(xiàn)自己不得不掌握大量關(guān)于協(xié)議狀態(tài)和狀態(tài)轉(zhuǎn)換的細節(jié)，并且即便非常小心，代碼中也總會出現(xiàn)難以察覺的漏洞。
3、Elixir：并不夠好的繼任者
面對無比痛苦的迭代工作，始終無法解決內(nèi)存安全問題的Ockam決定放棄C語言，并為項目尋找更適合的繼任者——彼時的他們將視線投到了以Erlang為基礎(chǔ)的Elixir語言之上。
Elixir程序運行在Erlang虛擬機BEAM上，BEAM提供了Erlang過程。Erlang流程是輕量級有狀態(tài)并發(fā)參與者。由于actors可以在維護內(nèi)部狀態(tài)的同時并發(fā)運行，所以運行一個并發(fā)的有狀態(tài)協(xié)議堆棧Ockam傳輸+Ockam路由+Ockam安全通道非常容易。
圖片
但令人遺憾的是，Elixir天然為支持高負載項目而生，無法像C語言一樣在小型或受限的計算機上擁有良好的運行表現(xiàn)，此外生態(tài)并不夠成熟的Elixir也無法成為某些特定語言管理包裝器的良好選擇。
4、Rust：令人興奮的探索之旅
在經(jīng)歷了接二連三的失敗后，Ockam團隊意識到他們的需求核心是在保障安全性的前提下實現(xiàn)輕量級的actors，但無論是C語言還是Elixir都無法做到完美適配。從這時起，Wadhwa開始帶領(lǐng)團隊研究Rust，并很快發(fā)現(xiàn)了這門語言獨特的魅力。
與C語言調(diào)用約定（calling convention）的兼容
Rust庫能夠?qū)С雠cC調(diào)用約定兼容的接口。這意味著任何靜態(tài)/動態(tài)鏈接或調(diào)用C庫中函數(shù)的語言都能夠以完全相同的方式調(diào)用Rust庫中的函數(shù)。并且由于大多數(shù)語言都支持C中的原生函數(shù)，所以他們也支持Rust中的原生函數(shù)，從包裝器的角度來看，Rust和C幾乎沒有任何區(qū)別。
支持多目標
Rust使用LLVM編譯，這意味著它可以針對非常多的計算機。這個集合不像C用GCC和專用的GCC分支所能達到的那樣大，但仍然是一個非常大的子集。隨著新的LLVM目標和Rust中潛在的GCC支持的增長，這能夠滿足Ockam到處運行的需求。
強大的內(nèi)存安全性
Rust的內(nèi)存安全功能消除了釋放后使用、雙重釋放、溢出、越界訪問等許多常見錯誤的可能性。根據(jù)此前的調(diào)查，這些錯誤會導致C或C++庫中60-70%的嚴重漏洞。Rust在編譯時提供了這種安全性，使其在編寫需要高性能、受限環(huán)境中運行并高度安全的代碼時具有很大的優(yōu)勢。
Async/await
讓研發(fā)團隊堅信Rust與Ockam能成為天作之和的最后一個原因是Rust中的async/await。Ockam需要輕量級的actors來創(chuàng)建簡單而安全的協(xié)議棧接口。async/await意味著在tokio和async-std這樣的項目中已經(jīng)完成了大量創(chuàng)建actor的工作，團隊能夠很輕松地在此基礎(chǔ)上構(gòu)建Ockam的actor實現(xiàn)。
5、最終的天作之合
基于Rust的async/await無論在大型計算機還是微型計算機上運行，都可以向用戶呈現(xiàn)完全相同的界面。位于Ockam Workers上的協(xié)議接口也可以在任何不同地方運行的情況下呈現(xiàn)完全相同的簡單接口。
最終，在Wadhwa的帶領(lǐng)下，Ockam放棄了系統(tǒng)內(nèi)的數(shù)萬行C語言代碼，并利用一段時間完成了向Rust的全面轉(zhuǎn)型。在經(jīng)歷了重寫后的多次穩(wěn)定性迭代后，如今任何用戶都能夠使用重獲新生的Ockam包，在任何設(shè)備上利用簡單函數(shù)調(diào)用創(chuàng)建他們想要的端到端的加密和相互認證的安全通道。
更重要的是，依托于Rust的內(nèi)存安全優(yōu)勢，這個函數(shù)調(diào)用的背后能夠隱藏所有潛在的復雜性和漏洞風險。
6、值得期待的未來
在Rust日漸趨于宏大的敘事中，Ockam的故事其實只是一個縮影。對如今絕大多數(shù)受困與內(nèi)存安全問題的項目而言，使用Rust或基于Rust進行重構(gòu)已不再是一項實驗或賭注，而是切實可行且足夠可靠的解決方案。
在Ockam之前，微軟已于4月宣布，出于對內(nèi)存安全的考慮，將使用18萬行Rust代碼重寫核心Windows庫；Python Web框架Flask的作者Armin也在Python 2023發(fā)展趨勢的文章中提出了將Rust融入Python項目和工具的想法；Ruff創(chuàng)始人在成立新公司時，同樣宣稱了要在未來通過Rust徹底改變Python生態(tài)。
更值得欣喜的是，Rust的進化如今仍在繼續(xù)，根據(jù)其發(fā)布的Rust 2024路線中顯示，官方團隊將在未來繼續(xù)在降低學習門檻、壯大生態(tài)連接等方面努力，幫助Rust盡快撕下被人詬病的“曲高和寡”的標簽，讓其盡快在更多場景中發(fā)揮價值。對此，Rust的未來，的確值得我們每個人的期待。
參考鏈接：
https://www.ockam.io/blog/rewriting_in_rust
