編譯 | 王瑞平、言征

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

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

1、ust需要調(diào)用其它語言完成任務

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

毫無疑問，linux在列表中出現(xiàn)次數(shù)最多。

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

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

2、內(nèi)存模型：用Rust語言開發(fā)Linux內(nèi)核的攔路虎

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

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

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

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

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

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

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

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

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

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

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

1）編譯時間

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

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

2）學習難度

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

3）過于嚴格

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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