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

选择一种编程语言可能很复杂，但是一些企业发现切换到Rust是一个相对容易的决定。

图片来源： geralt via Pixabay, CC0

为项目选择编程语言通常是一个复杂的决定，尤其是当涉及从一种语言切换到另一种语言时。 对于许多程序员来说，这不仅是一个技术考验，而且是一个深刻的情感抉择。 由于缺乏已知或可衡量的标准来选择一种语言，这往往意味着选择会陷入一系列情感诉求。

我参与过许多关于选择一种编程语言的讨论，他们通常以两种方式中的一种得出结论: 要么决定是使用可测量的，但不重要的标准，而忽略了相关性，但很难衡量标准; 要么决定是使用传言和情感诉求。

我参与了一个相当顺利的语言选择过程，那就是Microsoft内部越来越多地考虑使用Rust 。

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

选择语言的标准

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

技术指标

第一组标准是技术上的考虑。 它们通常是最容易想到的，因为它们最容易测量。有趣的是，技术成本(例如，构建系统集成、监视、工具、支持库等等)通常比技术效益更容易衡量。 这对采用新的编程语言尤其不利，因为采用这些语言的缺点往往是最明显的部分。

虽然有些技术好处(如性能)可以相对容易地测量，但其他好处则难以测量。 例如，动态类型系统(如 Python)相对于相对冗长和功能较差的系统(如 Java)有哪些优点? 与更强大的类型系统(如 Scala 或 Haskell)相比，这些优点又有哪些变化？ 许多人有强烈的直觉，认为这种技术上的差异应该在语言方面非常严肃地对待，但是它们并不是衡量这些差异的好方法。

测量难易程度方面的差异的一个副作用是，在决策过程中，最容易测量的项目往往得到最大的权重，即使有完美信息的情况并非如此。 这不仅使成本 / 收益分析无法进行，而且也使得对不同的成本和收益分配重要性的过程无从谈起。

组织标准

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

l 用这种语言雇用开发人员有多容易？

l 实施编程标准有多容易？

l 开发人员平均能够多长时间交付软件？

组织标准的成本和收益很难衡量。 人们通常会对他们有模糊的“直觉”答案，这会在此问题上产生强烈的意见。 但是不幸的是，衡量这些标准通常非常困难。 例如，对于大多数人来说，很明显的是TypeScript允许程序员比C更快地向客户提供可运行的，相对没有错误的软件，但是，但是支持这一点的数据在哪里呢？

而且，将重要性权重分配给这些标准通常非常困难。 可以很容易地看出，与Scala相比，Go实施标准化的编码实践要容易得多（由于gofmt的广泛使用），但是要衡量一个公司从标准化代码库中获得的具体利益是极其困难的。

这些标准仍然非常重要，但是由于测量它们的困难，它们经常被忽略或通过传言来推理。

情绪准则

第三是情感标准，如果不是彻底摒弃，这些标准往往会被忽略。

在传统上，软件编程试图模仿更真实的“工程”实践，而技术方面的考虑通常是最重要的。 有人会认为编程语言是“公正的工具”，应仅根据技术标准进行衡量。 其他人则认为，编程语言可以在某些更具艺术性的方面帮助程序员。这些标准很难以任何有意义的方式进行衡量。

通常，这取决于程序员使用该语言的满意度（从而提高了生产力）。这些考虑因素可能会对程序员产生真正的影响，但是这如何转化为使整个团队受益却几乎无法衡量。

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

未知标准

最后，还有一组常常被忽略的标准，因为新的编程语言通常是根据当前使用的语言设置的标准来判断的。 新语言可能具有其他语言中没有的功能，所以很多人不熟悉它们。 没有接触到这些能力可能意味着评估者不知不觉地忽略或者淡化它们。

这些标准可以是技术性的(例如，Kotlin 数据类相对于 Java 构造的优点) ，组织性的(例如，Elm 错误消息对于教授那些新的语言有多大帮助) ，或者是情感性的(例如，Ruby 使程序员在编写它时的感受)。

由于这些方面很难衡量，而且完全不熟悉这些方面的人也没有现有的框架来根据经验、直觉或传闻来判断它们，因此它们往往被低估，而不是被完全忽视的、更容易理解的标准。

为什么选择Rust

这让我们回到了微软对 Rust 日益增长的满意程度。 我认为，迄今为止，关于采用 Rust 的讨论相对顺利，因为 Rust 提供了一个非常明确和令人信服的优势——不仅是相对于它寻求取代的语言(c + +) ，而且相对于业界实际可用的其它语言: 优秀的性能、高水平的控制能力和内存安全性。

微软之所以决定研究 Rust (和其他语言) ，是因为微软产品中大约70% 的通用漏洞（CVEs）披露与 c 和 c + + 中的内存安全问题有关。 当发现大多数受影响的代码库由于性能问题而不能用 c # 有效地重写时，搜索就开始了。 Rust被认为是唯一可能取代 c + + 的候选者。 虽然不是所有的东西都需要重新修改，但是它有一个与众不同的地方，使它比现在的替代方案更好: 能够消除微软近70% 的高危漏洞。

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

但是，已经采用Rust的Microsoft团队（例如IoT Edge Security Daemon）吹捧该语言的其他方面（特别是由于高级类型系统而导致的“正确性”），因为他们最热衷于对该语言进行更多的投资。 这些团队无法为这些标准提供可靠的度量，但是他们清楚地认识到，语言的这一方面非常重要。

对于微软使用Rust的情况，主要的评判标准碰巧是一个容易衡量的标准。 但是当一个组织最重要的问题难以衡量时会发生什么呢？ 这些问题同样重要，因为它们目前难以衡量。

现在怎么办？

在采用一种新的编程语言时，拥有明确可测量的标准非常重要，但这并不意味着难以测量的标准不真实，不应该被认真对待。 我们只是缺乏全面评估新语言的工具。

已经对该问题进行了一些研究，但尚未产生任何已被工业广泛采用的东西。 尽管在Microsoft内部，Rust的情况比较明确，但这并不意味着仅在有明确的技术原因的情况下才应采用新的语言。 除了评估传统语言（例如性能）之外，我们还应该更好地评估编程语言的更多方面。

采用Rust的道路刚刚从Microsoft开始，只有一个理由证明对Rust进行投资是不理想的。 当我们开始形成广泛的证据来进一步证明Rust的采用时，绝对有必要更好地量化这种理解，并能够以更客观的方式谈论它。

我们仍然不确定如何做到这一点，但请继续关注我们在这条道路上的更多内容。