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