存在一種完美的編程語言嗎？
存在一種完美的編程語言嗎？
Rust 語言因其并發安全性而深受眾多開發者的喜愛，曾在多個榜單上獲評最受歡迎編程語言。然而，現在有人花費大量時間編寫 10 萬行 Rust 代碼之后，撰寫博客闡明 Rust 語言的一系列缺點，以下是博客的主要內容。 我深入研究 Rust 是為了改進由 Xobs 編寫的 Xous 操作系統。Xous 是一個用純 Rust 編寫的微內核消息傳遞操作系統，是為了輕量級 (IoT / 嵌入式規模) 的安全優先平臺（例如 Precursor）而編寫的，用于 MMU 的硬件強制型頁面級內存保護。
一年來，我們為 Xous 操作系統添加了許多功能，包括網絡 (TCP/UDP/DNS)、用于模態和多語言文本的中間件圖形抽象、存儲（以加密的形式）、PDDB、可信啟動（trusted boot）以及密鑰管理庫等。
我們決定編寫自己的操作系統而不是使用 SeL4、Tock、QNX 或 Linux 等現有實現，是因為我們想真正了設備中每一行代碼都在做什么。特別是對于 Linux，它的源代碼庫非常龐大且動態，即使開源，也不可能搞清其內核中的每一行代碼。
因此，Xous 僅支持我們的平臺，以盡可能避免內核不必要的復雜性。 這樣減少應用范圍還意味著我們還可以充分利用 CPU 在 FPGA 中運行的優勢 。因此，Xous 以一種不尋常的 RV32-IMAC 配置為目標：具有 MMU + AES 擴展的配置。 FPGA 意味著我們有能力在硬件級別上修復 API 錯誤，從而使內核更加精簡。
這對于從 RAM 中處理諸如掛起和恢復之類的抽象破壞（abstraction-busting）進程尤其重要。 我們創建 Xous 時研究了大量的系統編程語言，最終 Rust 脫穎而出。當時它剛剛開始支持 `no-std`，它的特點是強類型、內存安全，具有良好的工具和新型生態系統。我個人是強類型語言的忠實擁護者，而內存安全性不僅有利于系統編程，還能使優化器更好地生成代碼，并且 Rust 適用于并發。
實際上，我希望 Precursor 有一個支持標記指針和內存功能的 CPU，類似于 CHERI。于是我們和 CHERI 研發團隊進行了一些討論，但顯然他們非常專注于 C 語言，也沒有足夠的帶寬來支持 Rust。
總體而言，C 比 Rust 需要 CHERI 多得多，他們的選擇是符合資源優先原則的。我們不使用 C 語言，但出于安全性考慮，我希望有一天 Rust 中會存在硬件強制型胖指針（fat pointer）。
然而，Rust 語言絕不是完美的，甚至給我們的開發帶來了很多問題。下面我列舉一下 Rust 的缺點。
語法混亂復雜
我發現 Rust 語法密集、繁重且難以閱讀，例如：
再比如，Rust 宏的可讀性也存在問題——即使是我自己編寫的一些 Rust 宏也「只是勉強工作」。
一種可靠的語言不應該存在這些語法問題。 Rust 的確很強大，它的標準庫中包含 HashMaps、Vecs 和 Threads 等數據結構，豐富且可用性高。然而，Rust 的「std」庫并沒有為我們構建可審計的代碼庫帶來任何好處。
Rust 不夠完善
我們編寫 Xous 的代碼時，引入了一個叫作「const generic」的新類型。在此之前，Rust 沒有原生能力來處理多于 32 個元素的數組，這個限制令人抓狂。 在編寫 Xous 的過程中，Rust 的內聯匯編、工作空間等功能逐漸成熟，這意味著我們需要重新審視已經寫好的代碼，以使關鍵的初始啟動代碼集成進我們構建的系統。
Xous 開發的第一年都是使用’no-std’完成的，代價是占用大量內存空間且復雜性高。盡管可以編寫一個只有預先分配的、靜態大小的數據結構的操作系統，但為了適應最壞情況下的元素數量，因此我們不得不推出一些自己的數據結構。 大約一年前，Xobs 將 Rust 的 `std` 庫移植到 Xous，這意味著我們可以在穩定的 Rust 中訪問堆，現在 Xous 與特定版本的 Rust 綁定。 `std` 庫從根本上將內存分配、線程創建等「不安全」的硬件結構轉變成了「安全」的 Rust 結構。
然而，我必須不斷提醒自己，擁有 `std` 庫并不能消除關鍵代碼中的安全漏洞風險——它只是將許多關鍵代碼移動到標準庫中。 Rust 有固定的更新周期，這意味著我們也必須定期更新 Xous ，以保持與語言的兼容性。 但這可能是不可持續的。
最終，我們需要鎖定代碼庫，但我沒有明確的退出策略。也許我們可以考慮仍然使用 `no-std` 以獲得穩定的 `alloc` 功能來訪問堆。但這樣我們就還需要使用 Vec、HashMap、Thread 和 Arc/Mutex/Rc/RefCell/Box 構造等，以使 Xous 能夠被有效編碼。
Rust 在供應鏈安全方面堪憂
在 rustup.rs 安裝文件中有如下代碼：
Crates.io 也存在一種拼寫錯誤，很難確定哪些 crate 是好或壞；一些完全按照用戶想要的名稱命名的 crate 放棄提供所需功能，而積極維護的 crate 必須采用不太直觀的名稱。當然，這不是 Rust 獨有的問題。 還有一個事實是，依賴項是鏈式的。也就是說當你從 crates.io 拉入一個東西時，你也會拉入該 crate 的所有從屬依賴項，以及它們所有的 build.rs (http://build.rs/) 腳本，這些最終都將在你的機器上運行。
因此，僅審核 Cargo.toml 文件中明確指定的 crate 是不夠的——您還必須審核所有相關 crate 是否存在潛在的供應鏈攻擊。 幸運的是，Rust 確實允許您使用 Cargo.lock 文件將 crate 固定在特定版本，并且可以完全指定依賴 crate 。我們試圖在 Xous 中通過發布 Cargo.lock 文件并將我們所有的一階相關 crate 指定為次要修訂的策略來緩解這個問題。
然而，我們的大部分調試和測試框架都依賴于一些相當花哨和復雜的 crate，這些 crate 引入了大量的依賴項，即使我嘗試為我們的目標硬件運行構建，在主機上運行的依賴 crate 和 build.rs 腳本還是被構建。 針對這個問題，我編寫了一個名為「crate-scraper」的小工具，它為我們的 Cargo.toml 文件中指定的每個源下載源包，并且將它們存儲在本地，這樣我們就可以獲得用于構建 Xous 版本的代碼快照。
它還運行一個快速的「分析」程序——搜索名為 build.rs 的文件并將它們整理到一個文件中，這樣我就可以更快地通過 grep 查找明顯的問題。
當然，手動審查并不是檢測嵌入在 build.rs (http://build.rs/) 文件中巧妙偽裝的惡意軟件的實用方法，但它至少讓我了解了我們正在處理的攻擊面的規模。令人驚訝的是，我們審查出來自各種第三方的大約 5700 行代碼，用于操作文件、目錄和環境變量，并在我的計算機上運行其他程序。 我不確定這個問題是否有更好的解決方案，但是，如果你的目標是構建可信賴的固件，請警惕 Rust 廣泛的軟件供應鏈攻擊面。
無法復現別人的 Rust 構建
我對 Rust 的最后一點看法是，一臺計算機上的構建無法在另一臺上復現。我認為這主要是因為 Rust 將源代碼的完整路徑作為內置到二進制文件中調試字符串的一部分。
這導致了一些糟糕的情況，例如我們在 Windows 上構建的工作成功了，但在 Linux 下卻失敗了，因為二者的路徑名非常不同，這會導致一些內存對象在目標內存中被轉移。 公平地講，這些失敗是由于 Xous 中存在錯誤，這些錯誤已經得到修復。
但是，最終仍會有用戶向我們報告我們無法復現，因為他們在構建系統上的路徑與我們的不同。
最后，我想說盡管這里列出了所有的怨言，但如果能重來，Rust 仍然是我們用于構建 Xous 所用語言的有力競爭者。我用 C、Python 和 Java 完成了很多大型項目，所有這些項目最終都背負著「不斷增加的技術債務」，而 Rust 可以規避這些問題。
審核編輯 ：李倩
Rust 語言因其并發安全性而深受眾多開發者的喜愛，曾在多個榜單上獲評最受歡迎編程語言。然而，現在有人花費大量時間編寫 10 萬行 Rust 代碼之后，撰寫博客闡明 Rust 語言的一系列缺點，以下是博客的主要內容。 我深入研究 Rust 是為了改進由 Xobs 編寫的 Xous 操作系統。Xous 是一個用純 Rust 編寫的微內核消息傳遞操作系統，是為了輕量級 (IoT / 嵌入式規模) 的安全優先平臺（例如 Precursor）而編寫的，用于 MMU 的硬件強制型頁面級內存保護。
一年來，我們為 Xous 操作系統添加了許多功能，包括網絡 (TCP/UDP/DNS)、用于模態和多語言文本的中間件圖形抽象、存儲（以加密的形式）、PDDB、可信啟動（trusted boot）以及密鑰管理庫等。
我們決定編寫自己的操作系統而不是使用 SeL4、Tock、QNX 或 Linux 等現有實現，是因為我們想真正了設備中每一行代碼都在做什么。特別是對于 Linux，它的源代碼庫非常龐大且動態，即使開源，也不可能搞清其內核中的每一行代碼。
因此，Xous 僅支持我們的平臺，以盡可能避免內核不必要的復雜性。 這樣減少應用范圍還意味著我們還可以充分利用 CPU 在 FPGA 中運行的優勢 。因此，Xous 以一種不尋常的 RV32-IMAC 配置為目標：具有 MMU + AES 擴展的配置。 FPGA 意味著我們有能力在硬件級別上修復 API 錯誤，從而使內核更加精簡。
這對于從 RAM 中處理諸如掛起和恢復之類的抽象破壞（abstraction-busting）進程尤其重要。 我們創建 Xous 時研究了大量的系統編程語言，最終 Rust 脫穎而出。當時它剛剛開始支持 `no-std`，它的特點是強類型、內存安全，具有良好的工具和新型生態系統。我個人是強類型語言的忠實擁護者，而內存安全性不僅有利于系統編程，還能使優化器更好地生成代碼，并且 Rust 適用于并發。
實際上，我希望 Precursor 有一個支持標記指針和內存功能的 CPU，類似于 CHERI。于是我們和 CHERI 研發團隊進行了一些討論，但顯然他們非常專注于 C 語言，也沒有足夠的帶寬來支持 Rust。
總體而言，C 比 Rust 需要 CHERI 多得多，他們的選擇是符合資源優先原則的。我們不使用 C 語言，但出于安全性考慮，我希望有一天 Rust 中會存在硬件強制型胖指針（fat pointer）。
然而，Rust 語言絕不是完美的，甚至給我們的開發帶來了很多問題。下面我列舉一下 Rust 的缺點。
語法混亂復雜
我發現 Rust 語法密集、繁重且難以閱讀，例如：
Trying::<&'aheavy>(syntax,|like|{this.can_be(maddening)}).map(|_|())?;
簡單來說，上面的代碼類似于在對象（實際上是 `struct`）上調用一個名為「to_read」的方法。 還有一種不遵循 Rust 語法規則的宏和指令也能運行：
#[cfg(all(not(baremetal),any(feature=“hazmat”,feature=“debug_print”)))]
上面的語句中最令我困惑的是使用‘=’來表示等價而不是賦值，因為配置指令中的內容不是 Rust 代碼，它就像一個完全獨立的元語言。再比如，Rust 宏的可讀性也存在問題——即使是我自己編寫的一些 Rust 宏也「只是勉強工作」。
一種可靠的語言不應該存在這些語法問題。 Rust 的確很強大，它的標準庫中包含 HashMaps、Vecs 和 Threads 等數據結構，豐富且可用性高。然而，Rust 的「std」庫并沒有為我們構建可審計的代碼庫帶來任何好處。
Rust 不夠完善
我們編寫 Xous 的代碼時，引入了一個叫作「const generic」的新類型。在此之前，Rust 沒有原生能力來處理多于 32 個元素的數組，這個限制令人抓狂。 在編寫 Xous 的過程中，Rust 的內聯匯編、工作空間等功能逐漸成熟，這意味著我們需要重新審視已經寫好的代碼，以使關鍵的初始啟動代碼集成進我們構建的系統。
Xous 開發的第一年都是使用’no-std’完成的，代價是占用大量內存空間且復雜性高。盡管可以編寫一個只有預先分配的、靜態大小的數據結構的操作系統，但為了適應最壞情況下的元素數量，因此我們不得不推出一些自己的數據結構。 大約一年前，Xobs 將 Rust 的 `std` 庫移植到 Xous，這意味著我們可以在穩定的 Rust 中訪問堆，現在 Xous 與特定版本的 Rust 綁定。 `std` 庫從根本上將內存分配、線程創建等「不安全」的硬件結構轉變成了「安全」的 Rust 結構。
然而，我必須不斷提醒自己，擁有 `std` 庫并不能消除關鍵代碼中的安全漏洞風險——它只是將許多關鍵代碼移動到標準庫中。 Rust 有固定的更新周期，這意味著我們也必須定期更新 Xous ，以保持與語言的兼容性。 但這可能是不可持續的。
最終，我們需要鎖定代碼庫，但我沒有明確的退出策略。也許我們可以考慮仍然使用 `no-std` 以獲得穩定的 `alloc` 功能來訪問堆。但這樣我們就還需要使用 Vec、HashMap、Thread 和 Arc/Mutex/Rc/RefCell/Box 構造等，以使 Xous 能夠被有效編碼。
Rust 在供應鏈安全方面堪憂
在 rustup.rs 安裝文件中有如下代碼：
`curl--proto'=https'--tlsv1.2-sSfhttps://sh.rustup.rs|sh`
用戶可以下載腳本并在運行之前對其進行檢查，這似乎比 vscode 的 Windows .MSI 安裝程序好得多。但是，這種做法遍及整個構建生態系統，讓我對通過 crates.io 生態系統發起的軟件供應鏈攻擊的可能性感到不安。 Crates.io 也存在一種拼寫錯誤，很難確定哪些 crate 是好或壞；一些完全按照用戶想要的名稱命名的 crate 放棄提供所需功能，而積極維護的 crate 必須采用不太直觀的名稱。當然，這不是 Rust 獨有的問題。 還有一個事實是，依賴項是鏈式的。也就是說當你從 crates.io 拉入一個東西時，你也會拉入該 crate 的所有從屬依賴項，以及它們所有的 build.rs (http://build.rs/) 腳本，這些最終都將在你的機器上運行。
因此，僅審核 Cargo.toml 文件中明確指定的 crate 是不夠的——您還必須審核所有相關 crate 是否存在潛在的供應鏈攻擊。 幸運的是，Rust 確實允許您使用 Cargo.lock 文件將 crate 固定在特定版本，并且可以完全指定依賴 crate 。我們試圖在 Xous 中通過發布 Cargo.lock 文件并將我們所有的一階相關 crate 指定為次要修訂的策略來緩解這個問題。
然而，我們的大部分調試和測試框架都依賴于一些相當花哨和復雜的 crate，這些 crate 引入了大量的依賴項，即使我嘗試為我們的目標硬件運行構建，在主機上運行的依賴 crate 和 build.rs 腳本還是被構建。 針對這個問題，我編寫了一個名為「crate-scraper」的小工具，它為我們的 Cargo.toml 文件中指定的每個源下載源包，并且將它們存儲在本地，這樣我們就可以獲得用于構建 Xous 版本的代碼快照。
它還運行一個快速的「分析」程序——搜索名為 build.rs 的文件并將它們整理到一個文件中，這樣我就可以更快地通過 grep 查找明顯的問題。
當然，手動審查并不是檢測嵌入在 build.rs (http://build.rs/) 文件中巧妙偽裝的惡意軟件的實用方法，但它至少讓我了解了我們正在處理的攻擊面的規模。令人驚訝的是，我們審查出來自各種第三方的大約 5700 行代碼，用于操作文件、目錄和環境變量，并在我的計算機上運行其他程序。 我不確定這個問題是否有更好的解決方案，但是，如果你的目標是構建可信賴的固件，請警惕 Rust 廣泛的軟件供應鏈攻擊面。
無法復現別人的 Rust 構建
我對 Rust 的最后一點看法是，一臺計算機上的構建無法在另一臺上復現。我認為這主要是因為 Rust 將源代碼的完整路徑作為內置到二進制文件中調試字符串的一部分。
這導致了一些糟糕的情況，例如我們在 Windows 上構建的工作成功了，但在 Linux 下卻失敗了，因為二者的路徑名非常不同，這會導致一些內存對象在目標內存中被轉移。 公平地講，這些失敗是由于 Xous 中存在錯誤，這些錯誤已經得到修復。
但是，最終仍會有用戶向我們報告我們無法復現，因為他們在構建系統上的路徑與我們的不同。
最后，我想說盡管這里列出了所有的怨言，但如果能重來，Rust 仍然是我們用于構建 Xous 所用語言的有力競爭者。我用 C、Python 和 Java 完成了很多大型項目，所有這些項目最終都背負著「不斷增加的技術債務」，而 Rust 可以規避這些問題。
聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規問題，請聯系本站處理。
舉報投訴
-
cpu
+關注
關注
68文章
11279瀏覽量
224993 -
操作系統
+關注
關注
37文章
7402瀏覽量
129307 -
編程語言
+關注
關注
10文章
1964瀏覽量
39571
原文標題：編寫完10萬行代碼，我發了篇長文吐槽Rust
文章出處：【微信號：CVSCHOOL，微信公眾號：OpenCV學堂】歡迎添加關注！文章轉載請注明出處。
發布評論請先 登錄
相關推薦
熱點推薦
汽車網絡安全開發語言選型指南：C/C++/Rust/Java等主流語言對比+Perforce QAC/Klocwork工具支持
汽車網絡安全如何選編程語言？C、C++、Rust、Java……誰更適合AUTOSAR、ISO/SAE 21434？一文了解8種主流語言的優劣
為什么單片機還在用C語言編程？
最適合單片機開發的編程語言實在太過晦澀難懂，學習起來非常的不方便，并且每一種單片機的匯編指令有很大區別，所以想把一個程序從這種單片機移植到另一種
發表于 11-28 07:37
C語言的編程技巧
一個成員是一個未知大小的數組，適用于動態分配內存并關聯一個可變長度的數組。?
?3、匿名結構體和聯合體?：C語言允許在結構體或聯合體中定義不帶標簽的內部結構體或聯合體，簡化代碼結構。
發表于 11-27 06:46
2025年最佳的嵌入式編程語言有哪些呢？
嵌入式系統是現代科技不可或缺的一部分。它們存在于家用電器、汽車、住宅、醫院、商店等各個領域。它們與我們的社會緊密相連。選擇合適的語言來構建嵌入式系統對于成功至關重要。那么，2025年最佳的嵌入式
C語言和單片機C語言有什么差異
的目標代碼短、運行速度高、存儲空間小、符合C語言的ANSI標準，生成的代碼遵循Intel目標文件格式，而且可與A51匯編語言PL/M51語言目標代碼混合使用。
4、C只是一種高級
發表于 11-14 07:55
一文了解Mojo編程語言
Mojo 是一種由 Modular AI 公司開發的編程語言，旨在將 Python 的易用性與 C 語言的高性能相結合，特別適合人工智能（AI）、高性能計算（HPC）和系統級
發表于 11-07 05:59
指令集測試的一種糾錯方法
本文描述在進行指令集測試的一種糾錯方法
1.打開測試指令集對應的dump文件
dump文件是指由匯編文件進行反匯編之后，可以供人閱讀指令的反匯編文件。其包含了每一條指令的具體操作的信息。指令集測試
發表于 10-24 14:04
C語言精彩編程百例-364頁
內容提要
C是一種通用的程序設計語言，它包含了緊湊的表達式、豐富的運算符集合、現代控制流以及數據結構等四個部分。C語言功能豐富，衣達能力強，使用起來靈活方便:它應用面廣，可移植性強，網時具有高級
發表于 06-13 17:28
深入理解C語言：C語言循環控制
在C語言編程中，循環結構是至關重要的，它可以讓程序重復執行特定的代碼塊，從而提高編程效率。然而，為了避免程序進入無限循環，C語言提供了多種循環控制語句，如break、continue和
工商網監
評論