在本系列文章中，我们探讨了主动采取一些措施消除一类漏洞的必要性，并介绍了在 Microsoft 的代码中发现的一些内存安全问题的例子，这些问题可以用其他语言避免。现在我们来看看为什么我们认为 Rust 是目前可用的 C 和 C++ 最好的替代品。
虽然，已经有许多非常好用的内存安全语言，广泛应用于微软内外，包括 .NET 语言（如 C# 和 F#）和其他语言（如 Swift, Go, and Python）。 我们鼓励正在使用 C 或 C++ 的人考虑使用这些语言中的一种。然而，我们正在讨论对安全的系统编程语言的需求（即，可以构建其他软件运行的系统的语言，如OS内核）。此类工作负载需要 C，C ++ 和 Rust 提供的速度和可预测的性能。通过垃圾回收实现内存安全的语言不是系统编程的理想选择，因为它们的运行时会导致不可预测的性能和不必要的开销。
性能和控制
在考虑为什么Rust是一个很好的替代方案时，最好考虑一下我们不能因为从 C 或 C++ 转换而放弃什么——即性能和控制。 Rust，就像 C 和 C++ 一样，有一个最小的和可选的“运行时”。Rust 的标准库依赖于 libc 来支持它的平台，就像 C 和 C++ 那样，但是标准库也是可选的，所以在没有操作系统的平台上也是可以运行的。
Rust 与 C 和 C++ 一样，也为程序员提供了对何时分配内存以及分配多少内存的细粒度控制，从而使程序员能够非常清楚地了解程序运行时将如何执行。这对于原始性能，控制和可预测性的性能意味着什么，Rust，C 和 C ++可以用类似的术语来思考。
安全
Rust 与 C 和 C++ 的区别在于其强大的安全保障。除非通过使用“unsafe”关键字明确选择使用，否则Rust完全是内存安全的，这意味着我们在上一篇文章中说明的问题是无法表达的。 在以后的文章中，我们将重新讨论这些示例，以了解 Rust如何在不添加任何运行时开销的情况下防止这些问题。正如我们所看到的，MSRC 分配给 CVE 的大约70%的安全问题是内存安全问题。 这意味着如果软件是用 Rust 编写的，那么70%的安全问题很可能已经消除。我们并不是唯一一家报道这一发现的公司。
在系统编程中，有时程序员必须执行无法静态验证为安全的操作。Rust 为程序员提供了将这些操作包装在安全抽象的工具中，这意味着Rust编译器可以静态地强制执行那些曾经属于代码注释或约定的操作。必须显式地标记内存不安全操作，从而极大地减少了安全专家必须仔细检查内存安全漏洞的面积。
不仅仅是性能和安全性
虽然 Rust 最初因为上述原因引起了 MSRC 的兴趣，但是微软的其他团队已经因为其他原因开始采用 Rust：
- 根据一项内部调查，采用的首要原因是“正确性”——这是 Rust 安全保障的延伸，可以实现“if it compiles, then it works”的格言。
- Rust 静态地强制执行程序的许多特性，这些特性超出了内存安范围，包括空指针安全性和数据竞争安全性(即，不允许从两个或多个线程非同步地访问一块内存)。
- 微软的许多团队都发现 Rust 的丰富类型系统使编写富有表现力的程序成为可能。具有相关数据的枚举和强大的特征系统等概念进一步强化了 Rust 的目标，即尽可能使程序减少 BUG。
- Rust 现有的社区对该语言有巨大的好处。语言的大部分功能来自于其核心之外的库、工具和学习资料。 Rust 仍然是一个年轻的语言，但是它拥有一个健康的生态系统，拥有一个活跃的、开放的编译器和语言的开发过程，并且它显示出了强大的促进开源社区和支持用户生产力的能力。这给了我们更多的理由相信该语言有一个光明的未来。
所有这些都解释了Rust过去四年在Stack Overflow最受欢迎的语言列表中高居榜首的记录。 虽然现在说采用 Rust 的规模和微软的工程组织一样大还为时过早，但早期采用 Rust 通常是非常积极的。
一个光明的未来
我们相信 Rust 会改变编写安全的系统软件的游戏规则。Rust 提供编写低级系统所需的性能和控制，同时允许软件开发人员编写健壮、安全的程序。
在研究 Rust 的过程中，我们发现了一些问题，这些问题一直困扰着我们。其中一些问题包括如何规范Rust的“不安全”超集的使用，缺乏与 C ++ 一流的互操作性，以及与现有Microsoft工具的互操作性。 我们将在以后的博客中讨论其中的许多问题，因为它们对微软的大规模采用构成了挑战，我们希望让 Rust 和更广泛的软件社区参与进来，帮助我们找到适合所有人的解决方案。
但我们对这些可能性感到兴奋。虽然还有许多问题有待解决，比如 Rust 如何融入微软的整个工程设计中，但是我们鼓励其他人加入我们的行列，认真研究这种语言，以满足他们的系统编程需求。
Ryan Levick, Principal Cloud Developer Advocate
