Rust 與信息學三定律

在JAVA領域工作了10年之后，最近我一直在更認真地研究Rust。我幾乎沒有開始Rust編程，但是我感到很熱情：我相信Rust應該引起注意，因為這是語言平衡的轉變。

tl; dr

Rust可以在嵌入式芯片，Web應用程序和分布式系統中運行。它結合了C的速度，C是一種現代的強類型系統，可以安全地管理內存和高質量的生態系統。它使編寫并發代碼變得簡單而安全。 Rust社區熱情，友好，非常活躍并且正在開發出色的軟件。 Rust已在生產中使用，并且可以正常工作，但某些零件仍在完善中。我要參加這個有趣的活動，不讓您知道:-)

從Java到Rust

Java和Rust是非常不同的語言，據認為它們針對不同的空間。有人問我為什么Java開發人員（無聊的開發人員）會對Rust感興趣。事實證明，我選擇Java的理由與現在將我引向Rust的理由相同。讓我描述指導我選擇語言和技術的原則：信息學的三定律！

信息學三定律

我將它們稱為"信息學三定律"。這些定律的內容可能不是很原始（不是真正的定律），但是像阿西莫夫的定律一樣，它們試圖找到最基本的正交公理，從中可以得出想要的特性。它們是盡力而為的法則，因為完美是我們無法掌握的。

開始了：

程序必須正確。
程序必須是可維護的，除非與第一法相沖突。
程序必須高效，除非與第一或第二定律相抵觸。

第一定律意味著程序在所有情況下都應按預期方式運行。這意味著軟件應盡量避免出現錯誤，安全問題，并且永遠不會崩潰。

第二定律意味著，程序應該經過精心設計和記錄（因為必須對代碼有很好的理解）和模塊化，因為不能維護大型組件。還應該有幫助開發人員維護程序的工具。由于設計清晰并且可以熟練掌握該語言，因此部分演進不應保證完全重寫，并且另一位開發人員應能夠進行必要的更改。

第三定律意味著，對于最可能的輸入，程序應趨向于在速度和資源消耗之間達到最佳的平衡，即根據其使用方式。這意味著我們應該為工作使用最佳的數據結構，以最佳的權衡取舍，因為大多數時候沒有全局最優，要適當地進行擴展計劃，并使代碼對運行它的計算機表示同情。

這三個法律共同為生機勃勃的生態系統和社區提出了要求。開發人員不能單獨編寫正確，可維護和高效的程序，因為現代程序所依賴的代碼比一個開發人員所能產生的更多。他們必須重用社區提供的組件。他們必須共享一個社區健康的信念，即社區正在成長，或者規模足夠大，可以維護現有組件，并且可以構建新組件。這使得在選擇編程環境時，圍繞語言的社區成為最重要的因素。

三定律的順序

正確性無疑是我們在軟件中的主要關注點。如果某個軟件不能正常工作，則不值得運行。如果不安全，則存在安全風險。這顯然使我們的第一定律正確無誤。

但是，人們可能會爭論，可維護性是否應比效率更重要，反之亦然。當完全忽略可維護性時，程序可能會獲得更好的性能，而僅考慮正確性和可維護性的編程可能會導致程序完全無效。

實際上，可維護性和效率是交織在一起的：圍繞高效解決方案構建好的架構。例如，圍繞Rope數據結構構建了Xi編輯器，旨在成為"未來20年"的高性能編輯器。自上而下地設計系統可能會阻止實現有效的解決方案；自下而上地設計它們可能會泄漏太多的實現細節，并阻止干凈的，松耦合的體系結構。

不過，如果某個軟件正確且高效，但無法維護，則僅是一個黑匣子。如果我們不了解，我們是否確信它是正確的？相反，效率低下但正確且可維護的程序可能仍然可以挽救。可維護性成為第二定律。

定律和語言

信息學三定律僅涉及程序。但是編程語言可以提供保證，構造，工具，執行環境，社區或生態系統，以幫助開發人員構建遵守法律的程序。讓我們看一些選項。

系統語言

C和C ++共享一些屬性。它們非常適合編寫快速，占用資源少的代碼。手動內存管理將安全交給開發人員（他們幾乎不記得他們離開手機的地方！）。 C沒有附帶電池，因此您經常需要重寫數據結構； C ++如此龐然大物，每個項目都定義了他們使用或不使用語言的哪一部分（google因不使用異常而聞名）。由于它們都不安全，因此依賴于另一個庫會增加安全漏洞的風險。

Go填補了C ++嚇跑開發人員的空白。它的目標是速度快，并使使用例程輕松編寫并發代碼。它是垃圾收集的，因此比C ++更安全。它具有一個簡單的類型系統，沒有泛型和代數數據類型，不支持代碼重用以及其他現代語言。盡管如此，它仍然有一個非?；钴S的社區，可能受到Google的光環的吸引，并跟隨Docker的腳步。

JVM生態系統

Java是一種相當簡單的常規語言。 Java的重用歷史悠久，在整合第三方工件方面可能是冠軍，有時使大型項目看起來像科學怪人的怪獸。 Java具有語言和虛擬機支持的出色工具。現代JVM"及時"編譯代碼，并將其轉變為高效的本機代碼。有不同的垃圾收集器提供不同的權衡。哦，我提到過Java社區很大嗎？

Kotlin試圖通過減少冗長程度并提供一個更強大的，可空值安全的類型系統來提供Java"語言"的替代方案。它主要針對JVM，并具有與Java相同的優勢（也有Kotlin / Native）。由JetBrains創建的工具顯然非常出色。現在已正式為Android開發提供支持，并且可以保留。

函數式編程語言或FP語言

Haskell和OCaml最初是作為研究項目開始的，但近年來在該行業中越來越受歡迎。它們很安全，提供了出色的設計原語（尤其是類型類和模塊）和編程模型，以我的經驗，這些模型會減少錯誤。它們都是垃圾-GC是為第一種FP語言LISP發明的。特別是Haskell，它是完全純凈的，具有很大的好處：所有效果（例如IO）都明確表示為類型，這使開發人員不必擔心意外發生的副作用，但會變得麻煩。他們的社區都包括許多研究人員，可幫助建立堅實的正式基礎。

還有更多語言

我不會再討論其他所有語言。有些人在其生態系統和社區方面具有非常明顯的優勢。 Python擁有出色的數據分析生態系統，Erlang幫助使用actor構建容錯分布式系統，Scala是Kotlin的更老，更狂的兄弟姐妹，Clojure和Racket是現代的Lisps，而TypeScript則試圖使JavaScript有意義！

第三定律的覺醒

確實有許多有趣的語言。他們中的大多數人都有自己的長處和好主意。他們有多少幫助愿意的開發人員遵循信息學三定律？

可維護性主要由良好的設計原語（也稱為語言構造），良好的工具和社區來解決。不同的學校對什么構成好的原語有不同的看法：我個人更喜歡現代的強類型FP語言選擇的那些。

除了可維護性之外，有兩種主流語言：具有手動內存管理的語言和具有垃圾回收的語言。由于我們的開發人員并不完善，因此手動內存管理也意味著不安全，因此缺乏正確性。在過去的25年中，垃圾收集雖然產生了開銷，但在新的主流語言中已成為事實上的標準，因為安全比絕對性能更重要。

Rust是第一種提出替代方案的流行語言-自動內存管理和無垃圾收集的安全性-它帶有功能強大的FP啟發性設計原語，可構建高級抽象等等。

如果我們現在可以安全地構建更高效的軟件，不是嗎？還是應該針對開發生產力進行優化？我們能同時擁有嗎？

一個新的挑戰者來了

Rust是一種系統編程語言，運行速度極快，可防止出現段錯誤并保證線程安全。（rust-lang.org）

Rust已經存在了一段時間，但是直到2015年Rust 1.0發行時才進行試驗。從那時起，該語言及其生態系統得到了發展并得到了極大的改善。它將持續改善數年，但是核心團隊致力于不破壞用戶代碼。

與Go一樣，Rust旨在為對系統編程感興趣的開發人員提供一種嚴肅的選擇。但是，它從語言研究和現有編程語言的成功經驗中更多地借鑒（雙關語意）。

Rust具有現代類型的系統，該系統可以自動管理內存并與邊界檢查一起確保安全地對其進行訪問。它具有泛型和接近Haskell類型類的特征系統。這實現了Rust所謂的零成本抽象：擁有出色的設計不應損害性能。 James Munns在嵌入式編程方面的精彩演講描述了Rust嵌入式工作組如何構建一組可重用的組件，以便在不犧牲執行成本的情況下在微型芯片上對各種類型的硬件操作進行抽象。

當我深入研究Rust資源時，從出色的Rust Book開始，然后在GitHub上尋找我可能感興趣的項目，我注意到這種毫不妥協的方法對社區和生態系統產生了多大影響。 Rust開發人員旨在獲得最佳的運行時效率，最準確的抽象和最強的執行安全性。顯然，它使Rust適用于低級編程，但對于許多更高層次的應用程序也非常有趣：盡管人們可以在Rust中編寫linux內核模塊，但它也用于構建REST Web應用程序，區塊鏈節點甚至單頁Web WebAssembly中的應用程序！讓我們再深入一點，看看它如何幫助編寫守法程序。

正確性

編寫正確的程序很困難。我們要完成的任務通常含糊不清。盡管如此，語言仍可以通過表現力十足而提供幫助，而無需程序員跳過障礙來提出問題。 Rust具有現代的語言結構：代數數據類型（在這里稱為枚舉），泛型，特征，類型別名，元組等。它還具有功能強大的元編程系統，該系統使用宏可以完成繁重的工作，例如生成序列化程序，特征實現或定義嵌入式DSL。同樣，Rust借鑒了Scheme和其后代Racket（它特別擅長構建DSL）的靈感，通過支持衛生宏來借鑒了出色的想法。

正確性的另一部分是沒有不確定的行為，安全問題和墜毀風險。 Rust通過使類型系統意識到所有權來在沒有垃圾收集器的情況下管理內存。資源由一個單一的變量綁定擁有，并且可以通過將變量傳遞給函數來轉移所有權：Rust稱其為移動資源（在某種意義上類似于C ++的move語義）。

當變量綁定超出其詞法范圍時，它所擁有的資源將被刪除-又名，已釋放（可以通過將其移入遺忘而更早地刪除該值）。盡管它們可以證明是"活著的"，但可以借用共享的方式不變地或以排他的方式可變地借用價值。這類似于C ++引用，但是它允許Rust編譯器證明不會對給定的數據結構進行共享，可變的訪問，并且開發人員不必擔心一件事。

最后但并非最不重要的一點是，Rust通過確保在線程之間不共享非線程安全值來保護開發人員免受許多并發問題的困擾。

有很多資源可以了解Rust的所有權和借用，但是我將展示一個簡單的示例。請注意，所有權的復雜性更高，特別是某些類型可以選擇復制而不是移動的事實。例如，"擁有"一個整數沒有意義，因為它是如此之小以至于可以被簡單地復制。 Rust編譯器也在不斷發展，變得更加智能，并允許更直觀的代碼。

在上面的代碼段中，創建了一個名為s的新字符串，并將其傳遞給函數foo。因為foo接受一個String而不是對String的引用，所以它獲取了所有權而不是僅僅借用它：將String移到foo。后來，仍然主要在嘗試打印s時，Rust編譯器會抱怨資源s已綁定，因此不再可用。該程序將無法編譯。

事實證明，foo返回一個不變的s，但是編譯器不知道它，并且任何開發人員也不會只看主函數，foo的簽名和String的特征。知道這些元數據就足以知道foo擁有所有權，而我們對該資源的訪問也會丟失。

為了使我們的程序編譯，我們可以簡單地打印newS。 Rust甚至讓我們再次稱它為s，這很棒，因為無論如何將s傳遞給foo后，s都不可用！下面的程序先打印" Bar"，然后打印" Foo"。

查看foo，它還會在名為s2的變量下創建另一個String。超出范圍時將被丟棄。到目前為止，這看起來很像自動內存管理，用于在C ++中分配給堆棧上的結構或Java中由GC管理的引用句柄。區別在于，資源（例如堆?；蚨逊峙涞膬却妫┦冀K只有一個所有者。

在這里，在foo中返回s2而不是s將把s2返回給調用者，程序將打印" Bar"" Bar"。順便說一句，如果您想知道為什么在調用println！之后s2仍然可以使用，那是因為它是println !！只借了它！最后，驚嘆號一目了然。是一個宏。

最后，沒有必要在此處分配字符串，因為" Foo"和" Bar"常量已經在二進制文件中。 Rust可以直接指向那里并獲得我們可以借用的"切片"。我們使用稱為＆str的類型，它可以是借來的String或切片！

可維護性

所有權系統不僅使程序執行安全，而且我認為這也使代碼更易于維護和重用。一目了然的功能或詞法范圍，Rust開發人員可以確定其變量的屬性。他們可以構建API，以更準確地傳達應如何使用它們，并從類型檢查器中尋求幫助。

讓我舉一些例子。在C語言中，編譯器不知道函數返回的指針有效的時間。在垃圾回收語言中，您可以存儲函數返回的所有引用，并防止釋放潛在的大塊內存。許多Java庫隨附文檔，描述了什么時候可以安全地調用哪些方法，對象將處于有效狀態的時間長短，并通過異常強制執行這些規則，或者讓您處理未定義行為的后果。當涉及多線程時，這變得更加困難。 Rust使得可以返回在編譯時已知的給定生命周期內可能有效的引用，提供副本或提供您愿意時可以處置的共享引用。

Rust附帶了Cargo，這是一個命令行實用程序，用于構建，管理依賴項（稱為Crates），運行測試，修復警告等。擁有社區認可的構建工具意味著可以將精力集中在那里。它有助于Cargo的開發人員做出不錯的選擇，例如支持使用開箱即用的包裝箱進行語義版本控制，使用人類可讀和可編輯的配置格式（TOML）或支持可復制的版本。還有rustfmt，這是一種自動格式化程序，可防止浪費時間手動格式化源文件以及關于tabs-vs-spaces的無休止的爭論（劇透警告：贏得了4個空格）。

盡管如此，Rust的工具仍在開發中。 Java開創了20年的先機，但是語言本身非常適合工具。 IDE應該如何在宏中支持DSL？時間會證明一切。有一個官方語言服務器，該服務器具有VSCode和Eclipse集成。還有一個IntelliJ IDEA插件。

Rust編譯器得到LLVM的支持，LLVM是具有高效優化器的成熟基礎架構。它也可以針對WebAssembly，這使Web應用程序可以用Rust編寫，并且可以允許在沙箱中運行不受信任的代碼。

效率

Rust速度很快，運行速度可與C媲美。因為它沒有垃圾收集器，所以沒有隱藏的成本-即使沒有停頓，GC代碼也會在單獨的線程中運行并消耗資源。

由于注重效率，因此社區很容易為所有事情運行基準。因為代碼共享既簡單又安全，所以我們可以重用高性能的數據結構。 Bryan Cantrill在最近的博客中比較了程序的C版本和Rust版本，并將40％的運行時改進歸因于使用了BTreeSet，這是Rust標準集合中的現成可用的高效數據結構。

Rust使用戶可以控制其數據結構的內存布局，并使間接表達明確。這不僅有助于編寫緩存友好的代碼，而且還可以與C接口。Rust的FFI與C一樣簡單，沒有開銷，這使得調用任何系統原語都很容易（但不安全，應適當包裝）。我們不愿意在Java中執行此操作，特別是出于穩定性方面的考慮-段錯誤將使JVM崩潰-但這可能很有用。例如，最快的Java Web服務器之一正在使用JNI調用Linux的epoll，并且似乎比Java的標準無阻塞網絡庫NIO更好。

說到這一點，如果我們阻塞了一個等待IO的線程，那就太快了。 Rust具有零成本的期貨，包括無阻塞，反壓的流。因為期貨和流鏈接可能變得很冗長，所以可能已經使用async / await編寫了慣用的Rust代碼之類的異步代碼。現在，await被實現為一個宏，但是正在進行使它成為標準Rust功能的工作。

Rust的旗艦無阻塞IO庫Tokio建立在期貨的基礎上，為無阻塞編程提供了一致且流暢的抽象。 Web框架使用Hyper HTTP庫依次使用Tokio。

在我看來，Rust的核心開發人員一直在積極尋求更好的想法，這是對Sun指導Java很久的"此處未發明"綜合癥的一種令人耳目一新的變化。在這些好主意中，Rust的特性和缺乏結構繼承性提供了出色的設計原語，可幫助構建模塊化且可維護的系統。

Rust開發人員在錯誤處理方面有了另一個不錯的選擇。 Rust具有Result <T，E>類型，可以是具有成功值的Ok（T）或具有錯誤的Err（E）。 Haskell程序員將識別出兩種類型。使用常規結構處理錯誤意味著可以使用所有常用的機制-包括模式匹配，將Result作為值傳遞或序列化它。

Rust還使用特質使代碼不那么冗長。像Java的Iterable及其foreach循環，或Haskell的monad表示法一樣，Rust除了特質外還使用了一些健康的語法糖，可以輕松構建自然的類型。

例如，當嘗試使用+操作時，將使用Rust的std :: ops :: Add特性。運算符重載在C ++中總是帶來負面影響，但這也是Python在數據分析方面如此強大的一個重要原因。 Numpy的數組和矩陣可以方便地支持我們在紙上使用的相同運算符。為了防止沖突，Rust僅允許定義特征的模塊或定義目標類型的模塊實現特征。這是進行自定義Point類型支持匯總的簡單示例。

社區與生態系統

可以看到Rust社區多年來為該語言及其生態系統做出的巨大努力。他們使從Rust開始的體驗非常愉快和熱情。我發現了一種精神，使所謂的"銹病"變得動人心魄。

Rust擁有官方論壇和討論渠道，您可以在其中獲得幫助，并可以與核心開發人員討論技術問題。一切都是公開開發和辯論的，歡迎貢獻。

每周時事通訊會提供更新和不斷改進的感覺。它選出了"每周一箱"，以宣傳社區的努力。它要求就問題進行幫助，有時甚至在Rust官方發行版中也是如此。

Rust社區在GitHub上非?；钴S，并將許多問題標記為任何想成為貢獻者的"第一好問題"。實際上，Rust中沒有像Apache或Eclipse這樣的開源基金會，但是有很強的自由軟件文化。 Mozilla提供了Rust的贊助-許多核心開發人員都是Mozilla的雇員-但隨后許多大型項目仍然存在于單獨的GitHub帳戶上。

社區仍然很緊張，每個人都在共同努力以建立一個完整的生態系統。為了安全起見，Rust開發人員基本上重寫了所有內容，以盡可能地依賴Rust代碼而不是包裝的C，C ++或Go庫。

開發人員可以將其包裝箱發布到crates.io。 Rust標準庫很小，甚至是可選的，通過設計，大多數常用功能的開發（例如期貨，序列化或日志記錄）都發生在不同的包裝箱中。一些包裝箱是通過RFC流程標準化的。

由于其品質和社區，Rust吸引了很多人才。 Rust具有出色的密碼學生態系統，用于并發和數據并行性的庫。您可能對使用QUIC感興趣嗎？有一個圖書館！您是否在考慮Haskell的Quickcheck？校驗！還是模糊測試？ GTK +用戶界面？沒問題！您喜歡GraalVM嗎？魯斯特有HolyJit！ Nom和Pest是用于解析的兩個庫。人們在Rust中編寫OpenGL視頻游戲，其他人則編寫網絡服務或WebAssembly VM。