Web和云开发,Rust会起飞?( 三 )


该函数的签名activate还显式地编码了 Rails 示例中隐含的许多信息 。同样 , 预期的时区activation_date在类型中是正确的 , 并且该函数返回Rust 的时区Result , 这清楚地表明调用它时可能会发生错误 。Result事实上 , Rust 编译器将要求处理的成功和错误变体 , 以便不会发生未处理的运行时异常 。
此外 , activation_date当调用函数时 , 函数的参数总是保证有一个值 , 因为 Rust 没有隐式可空性的概念(与 Java 不同) 。如果activation_date 可能在其计算位置没有值 , 则它可能无法Option<DateTime<Utc>>传递给函数activate , 因为它的类型与预期的不同DateTime<Utc> 。Rust 编译器只允许Some其变体的代码路径Option导致方法的调用activate , 以便activation_date保证在函数运行时有一个值 。
虽然这显然是一个相当简单的示例 , 但它很好地说明了 Rust 的两个主要优点:
(1)Rails 示例中隐含的许多概念和规则都是通过 Rust 代码中的类型显式传达的 。可以清楚地区分活跃用户和非活跃用户 , 对于日期字段 , 甚至预期的时区也被编码在类型中 。这种表现力使代码更容易理解 , 特别是对于代码库的新手来说 , 从而提高了可维护性 。
(2)Rust 还大大提高了可靠性 , 因为其他语言(包括 Java 或 Go 等类型化语言)中常见的整类错误将在编译时而不是运行时检测到 。编译器保证函数activation_date的参数activate具有值以及要处理的函数可能返回的任何错误 。
总体而言 , 当每个人都关注 Rust 的性能时 , Rust 带来的可靠性和可维护性方面的改进常常被忽视 。然而 , 这些好处对于项目的长期成功可能比纯粹的绩效数字更相关 。
四、Rust先苦后甜由于 Rust 的主要优点是可靠性、可维护性、效率和性能 , 因此该语言的用例显然是与这四个方面特别相关的用例 。但是 , 好处的代价是需要考虑在内 。
总体而言 , Rust 仍然需要比其他技术更高的前期投资 , 特别是与 Web 项目中常用的技术相比:
虽然像 JavaScript 和 Ruby 这样的语言是为了快速获得结果而设计的 , 但 Rust 则没有留下太多的自由度 , 并且要求程序在获得工作结果之前通过所有编译器的检查 。与这些语言相比 , 使用 Rust 就需要付出更多的初始工作 。此外 , 人们在使用 Rust 之前还需要翻越一座山——那就是掌握 Rust 独特的所有权系统 。
然而 , 当跨过项目的初始阶段并将视野扩展到更长的时间范围时 , 可维护性、可靠性和稳定性等方面变得极其重要 , 一开始使用 Rust 时进行的额外投资会随着时间的推移而带来回报——
Rust 应用程序更可靠 , 因此需要更少的时间投入到错误修复上 , 并且更易于维护 , 因此更容易与不断增长和变化的团队一起有效地工作 。
最后就会呈现出:Rust工作量先大后小 , 先苦后甜 。对于其他语言来说 , 情况往往是相反的:随着时间的推移 , 随着团队的成长 , 可靠性和可维护性挑战的影响变得更大、成本更高 , 工作量也会增加 。
五、用Rust前的几个问题根据 Rust 的优势和投入曲线 , 每当评估是否针对特定情况选择 Rust 时 , 需要回答的主要问题是:
(1)团队是否已经具备 Rust 专业知识(许多不使用 Rust 的团队实际上已经拥有专业知识 , 因为很多开发人员在空闲时间使用 Rust 编写代码)?
(2)可靠性方面有哪些要求?
(3)长期维护计划是什么?
(4)系统构建的规模有多大 , Rust 在托管方面可以节省多少钱?
(5)根据以上问题的答案 , 额外的初始投资值得吗?
虽然在某些情况下 , 结论是额外的初始投资不值得 , 但在某些情况下 , 评估显然对 Rust 有利 。我们看到的一些典型用例包括:
(1)对于实现产品关键业务逻辑的核心业务系统来说 , 可靠性、长期可维护性等方面是首要考虑的问题 。
(2)对于金融系统来说 , 通常对错误的容忍度很低 , 而 Rust 带来的稳定性的提高可能是一个决定性因素 。另外 , 性能是一项关键要求 , 在特定场景(例如交易系统)中具有明显的财务影响 。


推荐阅读