为什么选择 Rust 作为你的下一个编程语言

图片来自

geralt 通过 Pixabay, CC0

为一个项目选择编程语言通常是一个复杂的决定，特别是当它涉及到从一种语言切换到另一种语言时。对于许多程序员来说，这不仅是一项技术性的练习，也是一种深刻的情感体验。缺乏已知的或可衡量的标准来选择语言通常意味着选择会变成一系列情感诉求。

我参与过许多关于选择编程语言的讨论，它们通常以两种方式之一结束：要么使用可衡量但不太重要的标准做出决定，而忽略相关的但难以衡量的标准；要么使用轶事和情感诉求来做出决定。

我参与过一个语言选择过程，到目前为止，这个过程进行得相当顺利：微软内部对使用 Rust 的考虑正在增加。

本文将探讨与选择编程语言（特别是 Rust）相关的一些问题。它们是：选择编程语言通常使用哪些标准，尤其是在大型企业中，以及为什么这个过程很少能成功结束？为什么微软对 Rust 的考虑进展如此顺利，从中可以总结出哪些通用的最佳实践？

选择语言的标准

决定是否切换到新的编程语言有很多标准。一般来说，最容易衡量的标准是最常被谈论的，即使它们不如其他更难衡量的标准重要。

技术标准

第一组标准是技术方面的考虑；它们通常是首先想到的，因为它们最容易衡量。

有趣的是，技术成本（例如，构建系统集成、监控、工具、支持库等等）通常比技术收益更容易衡量。这尤其不利于新编程语言的采用，因为采用的缺点往往是图景中最清晰的部分。

虽然一些技术收益（如性能）可以相对容易地衡量，但其他收益则更难衡量。例如，动态类型系统（如 Python 中）相对于相对冗长且功能较差的系统（如 Java）的相对优点是什么？与更强类型的系统（如 Scala 或 Haskell）相比，这种优势又会发生怎样的变化？许多人强烈地感觉到，在语言选择中应该非常认真地对待这种技术差异，但没有好的方法来衡量它们。

衡量难易程度差异的副作用是，即使在信息完美的情况下并非如此，最容易衡量的项目也常常在决策过程中被赋予最大的权重。这不仅扰乱了成本/效益分析，也扰乱了为不同成本和收益分配重要性的过程。

组织标准

组织标准，这是第二个考虑因素，包括

在这种语言中招聘开发人员有多容易？
强制执行编程标准有多容易？
平均而言，开发人员交付软件的速度有多快？

组织标准的成本和收益很难衡量。人们通常对它们有模糊的“直觉”答案，这会产生对该问题的强烈看法。然而，不幸的是，通常很难衡量这些标准。例如，对大多数人来说，TypeScript 允许程序员比 C 更快地向客户交付功能正常、相对无 bug 的软件可能是显而易见的，但有什么数据可以支持这一点呢？

此外，通常非常难以给这些标准分配重要性权重。很容易看出，Go 比 Scala 更容易强制执行标准化的编码实践（由于 gofmt 的广泛使用），但要衡量公司从标准化代码库中获得的具体好处极其困难。

这些标准仍然非常重要，但由于难以衡量，它们通常要么被忽略，要么通过轶事来推断。

情感标准

第三是情感标准，这些标准即使没有被完全否定，也往往被忽视。

软件编程传统上试图模仿更真实的“工程”实践，在这些实践中，技术考虑通常是最重要的。有些人会认为编程语言“只是工具”，应该仅根据技术标准来衡量。另一些人会认为，编程语言在工作中一些更具艺术性的方面为程序员提供帮助。这些标准极其难以用任何有意义的方式来衡量。

总的来说，这归结为程序员在使用这种语言时感到多么快乐（以及因此产生的生产力）。这些考虑因素会对程序员产生实际影响，但这如何转化为使整个团队受益几乎是无法衡量的。

由于量化这些标准的困难，这通常被忽略。但这是否意味着编程语言的情感考虑对程序员或编程组织没有重大影响？

未知标准

最后，还有一组标准经常被忽视，因为新的编程语言通常是根据当前使用的语言设定的标准来判断的。新语言可能具有其他语言中没有的等效功能，因此许多人将不熟悉它们。没有接触过这些功能可能意味着评估者在不知不觉中忽略或淡化了它们。

这些标准可以是技术性的（例如，Kotlin 数据类相对于 Java 构造的优点），组织性的（例如，Elm 错误消息对于教导语言新手有多大帮助），或情感性的（例如，Ruby 在程序员编写时给人的感觉）。

因为这些方面难以衡量，而且完全不熟悉它们的人没有现有的框架可以根据经验、直觉或轶事来判断它们，所以它们通常被低估，相对于更易于理解的标准而言——即使没有被完全忽略。

为什么选择 Rust？

这使我们回到了微软内部对 Rust 日益增长的兴奋。我认为到目前为止，围绕 Rust 采用的讨论进行得相对顺利，因为 Rust 提供了一个极其清晰且引人注目的优势——不仅相对于它试图取代的语言（C++），而且相对于行业中几乎可用的任何其他语言：卓越的性能、高水平的控制以及内存安全。

微软决定调查 Rust（和其他语言）的原因是，微软产品中大约 70% 的常见漏洞和暴露 (CVE) 与 C 和 C++ 中的内存安全问题有关。当发现大多数受影响的代码库由于性能问题而无法有效地用 C# 重写时，搜索开始了。Rust 被认为是替代 C++ 的唯一可能候选者。它足够相似，不必重做所有内容，但它有一个差异化因素，使其比当前的替代方案在可衡量方面更好：能够消除微软近 70% 的最严重安全漏洞。

除了内存安全、性能和控制之外，还有其他原因使 Rust 具有吸引力（例如，强大的类型安全保证、成为一种非常受欢迎的语言等等），但正如预期的那样，它们很难谈论，因为它们很难衡量。总的来说，大多数参与选择过程的人更感兴趣的是验证语言的这些其他方面在感知上并不比 C++ 差，但是，由于衡量这些方面非常困难，因此它们不被认为是采用该语言的积极原因。

然而，已经采用 Rust 的微软团队，例如用于 IoT Edge Security Daemon 的团队，吹捧了该语言的其他方面（特别是由于高级类型系统而带来的“正确性”），认为这是他们最热衷于在该语言上投入更多资金的原因。这些团队无法为这些标准提供可靠的衡量标准，但他们显然已经形成了直觉，即该语言的这一方面极其重要。

在微软使用 Rust 的情况下，被判断的主要标准恰好是一个容易衡量的标准。但是，当一个组织最重要的问题难以衡量时会发生什么？这些问题并非因为目前难以衡量而变得不重要。