为什么选择 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 安全守护程序，吹捧了该语言的其他方面（特别是由于高级类型系统而带来的“正确性”），认为这是他们最热衷于进一步投资该语言的原因。这些团队无法为这些标准提供可靠的衡量标准，但他们显然已经形成了一种直觉，即该语言的这一方面极其重要。

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