點擊參加51CTO網站內容調查問卷

編譯 | 王瑞平、言征

使用Rust三年多了，我非常喜歡它。Rust不僅幫助我完成了很多任務，還開發出極其可靠的軟件。Rust讓推斷代碼的并發性和并行性變得更容易。

我可以繼續贊美Rust，但這并非本篇文章的重點。相反，這篇文章旨在揭露Rust的一些缺點，它有時會拖慢開發人員的進度，需要調用其它語言才能完成任務。

1、Rust需要調用其它語言完成任務  

Rust中沒有具體調用系統命令的方法，得通過crates.io實現此功能。7年前，syscall crate進行了最后一次更新，支持以下平臺：

毫無疑問，Linux在列表中出現次數最多。

不過，如果你仍只使用FreeBSD操作系統而不使用x86_64，你就out了。如果你只關心NetBSD、OpenBSD或Solaris，你只能get到普通的技能。此時，你可以采取的措施是使用libc crate。

我認為這些方式都不太好，這不是系統編程語言該有的狀態。系統編程語言應該可以與其它編程語言互操作，不需要通過調用C語言完成任務。

2、內存模型：用Rust語言開發Linux內核的攔路虎 

上述列表中出現最多的當屬Linux。最近幾年，Rust For Linux項目隨著Rust的火爆也開始逐漸升溫。但是，Rust想深入Linux的真正核心仍有很長的路要走，最大的攔路虎是內存模型方面的問題。

當Rust編寫“無限接近計算機底層”的操作內核時，內存模型會變得很重要。它是多線程環境能夠可靠工作的基礎，需要對多線程環境的運作細節進行完備的定義。

Rust中的lock鎖是與具體要保護的數據是有強綁定關系的，開發者需要調用data.lock將鎖進行鎖定，只有這樣才能受鎖保護的數據才能被訪問。

由于Rust的變量都是有嚴格的生命周期及借用機制的，因此，鎖也很可能要在內存中移動，內存中對象的移動、所有權借用等除了造成移動鎖之外還會有移動構造函數等問題。

但是移動鎖、還移動構造函數這些概念在之前的Linux中幾乎是聞所未聞的。這些問題在Rust只開發上層應用時都不是問題，但一旦深入到操作系統內核，這些就都成了問題。所以，Rust想真正深入到Linux的內核當中還有很多的路要走。

3、麻煩：你只在GitHub上才能獲得crates包

一旦部分技術人員放棄使用crates包，隨著時間的推移更多人會放棄。我并不是唯一批判這個系統缺陷的人。

最重要的是，crates.io的注冊列表只在GitHub上才能get到。這意味著，為了使用crates.io，你必須擁有一個GitHub帳戶。對于一些開發人員來說，這顯然不是問題，但是，并不是所有程序員都能夠適應這種形式。

總之，就個人而言，我認為Rust在GitHub上托管他們的代碼糟糕透了。

4、不吐不快：Rust中那些突出的缺陷  

除了上述的“吐槽”，Rust編程語言還有一些明顯的缺點，在這里做個總結：

1）編譯時間   

與其對等的編程語言相比，Rust編譯代碼的速度相對較慢。原因是它的“編譯單元”不是單個文件，而是上文提到的crate包。 

crate可以包含多個模塊。因此，它們可以是大型編譯單元。雖然完成了whole-of-crate優化，但是，它還需要whole-of-crate編譯，這很耗時。此外，它還具有一個復雜的編譯器工具鏈，該工具鏈包含多個中間表示，并向LLVM發送大量代碼。這些都是導致Rust編譯代碼速度變慢的原因。 

2）學習難度   

真正學會Rust很難，為了理解它的主要部分，你需要先熟悉C++ 或任何面向對象的語言。

3）過于嚴格   

在編程方面，嚴格通常被認為是一件好事，但是，Rust有時有點過于嚴格，使用它進行編程時很難偷懶。直到一切都恰到好處，程序才會正確運行。

五、替代品：Zig，小巧而簡潔  

除了Rust，另一種真正引起我注意的語言是Zig。它在編譯時計算和執行命令，而不是像Rust一樣在運行時執行命令。很多程序員已經通過實踐證明了這一點。Zig不僅成為了完美的替代品， 對于維護任何類型的宏觀系統也都游刃有余。

Zig編程語言最主要的優點是小巧而簡潔，正廣受程序員好評。它專注于調試你的應用程序，而不是調試你的編程語言知識，沒有隱式控制流、沒有隱式內存分配、沒有預處理器，更沒有宏。

此外，用Zig編寫的庫可以在任何地方使用，包括：桌面程序和游戲、低延遲服務器、操作系統內核、嵌入式設備等。

Zig還提供了defer和errdefer，使所有的資源管理（不僅是內存）變得簡單且易于驗證。

六、寫在最后：Rust仍是理想語言 

總之，拋開上述缺陷不談，我仍認為Rust非常接近我的理想語言。但實際上，我也正在尋找其它語言。

我相信，當聽到批評的聲音后，Rust可以已經開始變革并反思了，也許，更好的解決方案即將出現。這需要一群人共同改進這種語言才不會重復同樣的錯誤。

當然，我對Rust抱怨主要針對crates.io，相信此類問題在不久的將來都能得以解決。

所以，無論如何，讓我們盡情幻想“后Rust時代的理想語言”。這種語言應該與Rust類似，同時具有Zig語言comptime的優勢。

新的語言中會有borrow checker，它就像Rustc編譯器一樣可以檢測出錯誤的消息。我們也會更多的支持comptime概念的出現而并非宏。與Rust不同，這種新語言能夠從頭至尾完成各種任務。

在新語言中，我們可獲得接口等內置功能并能夠直接與其它語言以及底層操作系統內核通信。最后，我還設想出一個庫包生態系統，它將是完全分布式和去中心化的。

雖然Rust有缺點，但它仍然是迄今為止在內存訪問、安全性和準確性方面最好的語言。我提到的很多小抱怨都只是從普通程序員角度出發的。

原文鏈接：https://jeang3nie.codeberg.page/rust-criticism-from-rustacean/