在本系列文章中，我們探討了主動采取一些措施消除一類漏洞的必要性，并介紹了在 Microsoft 的代碼中發(fā)現的一些內存安全問題的例子撕瞧，這些問題可以用其他語言避免。現在我們來看看為什么我們認為 Rust 是目前可用的 C 和 C++ 最好的替代品狞尔。
雖然丛版，已經有許多非常好用的內存安全語言，廣泛應用于微軟內外偏序，包括 .NET 語言（如 C# 和 F#）和其他語言（如 Swift, Go, and Python）页畦。 我們鼓勵正在使用 C 或 C++ 的人考慮使用這些語言中的一種。然而研儒，我們正在討論對安全的系統(tǒng)編程語言的需求（即豫缨，可以構建其他軟件運行的系統(tǒng)的語言，如OS內核）端朵。此類工作負載需要 C好芭，C ++ 和 Rust 提供的速度和可預測的性能。通過垃圾回收實現內存安全的語言不是系統(tǒng)編程的理想選擇冲呢，因為它們的運行時會導致不可預測的性能和不必要的開銷舍败。
性能和控制
在考慮為什么Rust是一個很好的替代方案時，最好考慮一下我們不能因為從 C 或 C++ 轉換而放棄什么——即性能和控制敬拓。 Rust邻薯，就像 C 和 C++ 一樣，有一個最小的和可選的“運行時”乘凸。Rust 的標準庫依賴于 libc 來支持它的平臺厕诡，就像 C 和 C++ 那樣，但是標準庫也是可選的翰意，所以在沒有操作系統(tǒng)的平臺上也是可以運行的木人。
Rust 與 C 和 C++ 一樣信柿，也為程序員提供了對何時分配內存以及分配多少內存的細粒度控制冀偶，從而使程序員能夠非常清楚地了解程序運行時將如何執(zhí)行。這對于原始性能渔嚷，控制和可預測性的性能意味著什么进鸠，Rust，C 和 C ++可以用類似的術語來思考形病。
安全
Rust 與 C 和 C++ 的區(qū)別在于其強大的安全保障客年。除非通過使用“unsafe”關鍵字明確選擇使用霞幅，否則Rust完全是內存安全的，這意味著我們在上一篇文章中說明的問題是無法表達的量瓜。 在以后的文章中司恳，我們將重新討論這些示例，以了解 Rust如何在不添加任何運行時開銷的情況下防止這些問題绍傲。正如我們所看到的扔傅，MSRC 分配給 CVE 的大約70%的安全問題是內存安全問題。 這意味著如果軟件是用 Rust 編寫的烫饼，那么70%的安全問題很可能已經消除猎塞。我們并不是唯一一家報道這一發(fā)現的公司。
在系統(tǒng)編程中杠纵，有時程序員必須執(zhí)行無法靜態(tài)驗證為安全的操作荠耽。Rust 為程序員提供了將這些操作包裝在安全抽象的工具中，這意味著Rust編譯器可以靜態(tài)地強制執(zhí)行那些曾經屬于代碼注釋或約定的操作比藻。必須顯式地標記內存不安全操作铝量，從而極大地減少了安全專家必須仔細檢查內存安全漏洞的面積。
不僅僅是性能和安全性
雖然 Rust 最初因為上述原因引起了 MSRC 的興趣银亲，但是微軟的其他團隊已經因為其他原因開始采用 Rust：
- 根據一項內部調查款违，采用的首要原因是“正確性”——這是 Rust 安全保障的延伸，可以實現“if it compiles, then it works”的格言群凶。
- Rust 靜態(tài)地強制執(zhí)行程序的許多特性插爹，這些特性超出了內存安范圍，包括空指針安全性和數據競爭安全性(即请梢，不允許從兩個或多個線程非同步地訪問一塊內存)赠尾。
- 微軟的許多團隊都發(fā)現 Rust 的豐富類型系統(tǒng)使編寫富有表現力的程序成為可能。具有相關數據的枚舉和強大的特征系統(tǒng)等概念進一步強化了 Rust 的目標毅弧，即盡可能使程序減少 BUG气嫁。
- Rust 現有的社區(qū)對該語言有巨大的好處。語言的大部分功能來自于其核心之外的庫够坐、工具和學習資料寸宵。 Rust 仍然是一個年輕的語言，但是它擁有一個健康的生態(tài)系統(tǒng)元咙，擁有一個活躍的梯影、開放的編譯器和語言的開發(fā)過程，并且它顯示出了強大的促進開源社區(qū)和支持用戶生產力的能力庶香。這給了我們更多的理由相信該語言有一個光明的未來甲棍。
所有這些都解釋了Rust過去四年在Stack Overflow最受歡迎的語言列表中高居榜首的記錄。 雖然現在說采用 Rust 的規(guī)模和微軟的工程組織一樣大還為時過早赶掖，但早期采用 Rust 通常是非常積極的感猛。
一個光明的未來
我們相信 Rust 會改變編寫安全的系統(tǒng)軟件的游戲規(guī)則七扰。Rust 提供編寫低級系統(tǒng)所需的性能和控制，同時允許軟件開發(fā)人員編寫健壯陪白、安全的程序颈走。
在研究 Rust 的過程中，我們發(fā)現了一些問題咱士，這些問題一直困擾著我們疫鹊。其中一些問題包括如何規(guī)范Rust的“不安全”超集的使用，缺乏與 C ++ 一流的互操作性司致，以及與現有Microsoft工具的互操作性拆吆。 我們將在以后的博客中討論其中的許多問題，因為它們對微軟的大規(guī)模采用構成了挑戰(zhàn)脂矫，我們希望讓 Rust 和更廣泛的軟件社區(qū)參與進來枣耀，幫助我們找到適合所有人的解決方案。
但我們對這些可能性感到興奮庭再。雖然還有許多問題有待解決捞奕，比如 Rust 如何融入微軟的整個工程設計中，但是我們鼓勵其他人加入我們的行列拄轻，認真研究這種語言颅围，以滿足他們的系統(tǒng)編程需求。
Ryan Levick, Principal Cloud Developer Advocate
