對于MSRC團隊解釋他們認為RUST編程言語的原因，不僅限于RUST編程語言在編寫時能夠保證內存安全。

RUST編程語言圖1

“第一點是現已有許多出色的內存安全言語在微軟表里廣泛運用，包含 .NET 言語（像是 C# 或 F#）和其他言語（例如 Swift、Go 和 Python）。咱們鼓舞現在運用 C 或 C++ 的人將其間恣意一種言語納入考慮。不過現在議論的是對安全的體系編程言語的需求，此類作業負載需要 C、C++ 和 Rust 能夠供給的速度和可預測的功能。 經過廢物收回實現內存安全的言語不是體系編程的理想挑選，因為它們的運轉時間會導致不行預測的功能和不必要的成本。”

第二點是功能和操控

Levick 指出，最好先考慮一下無法從 C 和 C++ 拋棄的東西——功能和操控，就能更清楚地理解 Rust 為什么是一個好的挑選。像 C 和 C++ 相同，Rust 有一個最小的可選“運轉時”。Rust 的規范庫同樣依賴于 libc，但規范庫也是可選的，因此在沒有操作體系的平臺上運轉也是可能的。

依然像 C 和 C++ 相同，Rust 為程序員在何時分配內存以及分配內存的多少上供給了精細的操控，使程序員能夠十分清楚地知道程序每次運轉時的確切履行方法。在原始速度、操控和可預測性方面，這對于功能來說意味著什么？那就是，“Rust、C 和 C++ 能夠用相似的術語來考慮”。

RUST編程語言圖2

第三點是安全

Rust 與 C 和 C++ 的區別在于其強大的安全保障，某種程度上來說 Rust 完全是內存安全（memory safe）的。正如之前那篇文章提到的，微軟大約 70% 的安全問題是內存安全問題。假如這些軟件用 Rust 編寫，那么這 70% 的安全問題很可能就不存在。

在體系編程中，有時程序員有必要履行無法靜態驗證為安全的操作。Rust 為程序員供給了將這些操作封裝在安全籠統中的東西，這意味著曾經降級為代碼注釋或約定的東西能夠由 Rust 編譯器靜態強制履行。

第四點是不僅僅是功能與安全

RUST編程語言圖3

Rust 最初引起 MSRC 的興趣正是因為上述功能與安全方面的特性。但它的的魅力不止于此，現已有其他微軟團隊開端選用 Rust，主要出于以下原因：

根據微軟內部查詢，選用它的最主要原因是“精密性”（correctness）——“if it compiles，then it works”。

Rust 靜態地強制履行程序的許多特點，現已遠超內存安全性，還包含空指針安全性和數據爭用安全性（即沒有來自兩個或多個線程的一塊內存的不同步訪問）。

Rust 的豐厚類型體系使編寫富有表現力的程序成為可能。 具有相關數據的枚舉和強大的 trait 體系等概念進一步強化了 Rust 的方針，即盡可能使程序無過錯。

Rust 現有的社區對該言語有很大好處。雖然 Rust 依然是一種年輕言語，但它擁有一個健康的生態體系，既能夠促進開源社區發展強大，又能夠支持出產用戶。

Levick 表明有滿足的理由相信 Rust 會有一個光明的未來，“雖然現在大規模選用 Rust 還為時過早，但前期選用 Rust 通常是十分活躍且正面的”。他們相信 Rust 在編寫安全的體系軟件時會改變游戲規則。Rust 供給編寫底層體系所需的功能和操控，一起使軟件開發人員能夠編寫更強健、安全的程序。

不過，MSRC 在研究 Rust 時發現了一些問題，其間包含怎么規范 Rust 的“不安全”（unsafe）超集的運用，缺乏與 C++ 的一流互操作性，以及與現有 Microsoft 東西的互操作性。這確實對微軟選用 Rust 提出了挑戰，但 MSRC 還是滿懷等待：“咱們對這些可能性感到振奮。 雖然還有許多關于 Rust 怎么習慣整個 Microsoft 工程的問題需要弄清楚，但咱們鼓舞其他人一同加入，認真考慮這門言語，以滿足他們的體系編程需求。”