出品 | OSC开源社区（ID：oschina2013)
微软首席工程师 Nick Cameron 发布了一篇博客，指出了他认为现在和未来几年 Rust 将面临的十大挑战，并提出了一些初步的解决方案想法。目前，Nick Cameron 主要负责该公司 Rust 相关的工作；曾经，他还是 Rust 核心团队的成员。
Nick 指出，现如今 Rust 正处于一个良好的发展局面；受欢迎程度越来越高、贡献者越来越多，还在一些重要领域进行了应用。但在这个充满变化的时代，从一个研究项目到一个新的、快速变化的语言再过渡到一个流行的、成熟的项目，是一个困难的演变过程。
“在这里，我想描述一下我认为现在和未来几年 Rust 面临的十大挑战。我有一些解决方案的想法，但它们都是大而难的问题，没有简单的答案，所以真正的解决方案都需要迭代、精力和创造力。我的重点是核心项目；社区和生态系统面临许多挑战（例如，如何使用 Rust 制作 GUI，或者如何让更多的 crates 进入 1.0），我认为这些挑战必须主要由社区来解决。”
治理挑战
开源工作中，在什么是对项目最有利的，以及什么是志愿贡献者想做的之间总存在着一些矛盾。现在，随着 Rust 社区逐渐发展壮大且 Mozilla 结束直接支持，Rust 中的这种紧张关系似乎也在日益加重。尽管有很多人从事基本的维护工作，但往往人手不足；一些重要领域也缺乏资源、缺乏引导贡献的战略工作或努力。
Nick 认为，在某些方面，采用自上而下的方法可能会更容易；但此举也或将导致 Rust 失去作为开源项目所拥有的一些优势。最大的挑战是确保在完成重要但不吸引人的工作的同时，同时又不失去项目中使其令人敬畏的部分特性。Nick 表示，他们目前正在努力解决一些具体问题，包括：
“与这一挑战相关的是在面对增长时保持 Rust 的基本特征。特别是，项目如何发展并接受新的贡献者和领导者（以及随之而来的不可避免的变化）而不忽视 Rust 的核心使命？随着观察者（和评论者）数量的增加，我们如何在讨论和决策中继续保持公开和透明？”
Rust 的多样性状况很糟糕。尽管在成为一个包容性项目方面 Rust 做的可能还不错，但还是有诸多贡献者因为某些消极原因而不得不离开了该项目；避免倦怠也是包容性的一部分。
“包容性的一个重要方面是能够容纳各种意见。如果我们只有在每个人都同意的情况下才能相处，那么我们就不可能多元化或包容。虽然我们对共识的偏好在某些领域对我们很有帮助，但它也带来了问题。我们避免冲突而不是解决冲突的文化是不健康的，并导致治理功能失调。这些真的很难解决！但我们必须优先解决它们，即使它们很困难，有时也很痛苦。”
Nick 称，过去的几年里在 Rust 飞速发展的同时，其流程和组织却并没有跟上步伐。在任何与治理或流程有关的事情上，都存在着巨大的变革惯性。即使现有的流程有大量的摩擦，但除了在此之上进行调整之外似乎也无可奈何。“我们已经积累了如此多的组织债务，以至于需要进行彻底的变革，但进行这种变革将是非常困难的。”
他认为，问题的核心是项目不愿意接受 “管理”（人员管理、项目管理、产品管理）作为项目领导的重要组成部分。这些事情可以独立于技术领导，但需要真正的权力委派（不仅仅是工作委派）。该项目面临的挑战是接受委托，支持这些活动，并引入更好地支持该项目的新流程。
生态系统挑战
4、Navigating the crate ecosystem
Rust 在最小标准库和 “batteries included” 之间取得了很好的平衡，原因在于其有一个繁荣的生态系统和易于使用的软件包管理器。然而，有关 crate 生态系统一直是个棘手的问题。存在很多 crates，要找到适合的则需要付出很多努力，或者说要很好地参与到社区中去。随着越来越多不是社区积极参与者用户的出现，以及 crate 数量的增加，这将成为一个更大的问题。
异步编程对于 Rust 目标的许多领域都很重要，且与 Rust 的编程模型配合得很好。然而，其生态系统在不同的运行时有些分裂；虽然有在进行相关的改进工作，但却进展缓慢，最终成功与否也未能确定。“风险在于我们最终会将东西带入标准库，这些东西并没有得到社区的广泛接受，我们最终会得到一个比我们开始时更糟糕的生态系统。”
技术挑战
6、如何在不失去其 core focus 的情况下使语言更具广泛吸引力？
Nick 认为 Rust 在其现有成功基础上仍有很大的增长空间。目前的很多软件都是用更侧重性能的语言编写，Rust 对安全、人体工程学和性能的关注则可以制造更好的产品并提高生产力。然而相对而言 Rust 学习难度和成本都太高，让 Rust 更容易学习和使用可能会扩大其影响力。
“我不认为支持 GC、对 Rc<RefCell<T>> 类型使用含糖语法或添加一堆语法糖是解决方案。我们必须在不失去 Rust 以系统编程为核心的优势的情况下让事情变得更简单。减少对 explicit lifetimes 的需求，使 borrow checker 更强大，不要使 trait system 过于复杂，关注用户体验，避免成为一种臃肿的语言，这些都会有所帮助。也许我们会发现可以显着简化所有权和生命周期的新 abstractions？”
安全性是 Rust 主要特色之一，也是许多人使用它的动力。因此需要能够为从事不安全工作的程序员提供更多支持和更好的体验。要做到这一点，则需要对 Rust 的内存模型有更清楚的了解，然后开发语言特性、库和工具。
幸运的是，这个领域有学术研究、出色的社区工作、MIRI、不安全代码指南等等。不幸的是，这是一个非常复杂和困难的领域，许多外围人士的意见会减慢进度，并增加相关人员的工作难度。Nick 指出，出于政治和技术原因，一些可能真正影响大的更改根本无法进行。
标准库除了单调增长之外没有其他方法可以发展（可以弃用但永远不会删除，并且无法更改）。就其本身而言，这将导致标准库变得越来越庞大和混乱。但也有二阶效应：必须对稳定性采取极其保守的态度，除了 “stable forever” 和 “仅在 nightly 可用且完全可能发生变化” 之外，API 没有其他可能的状态。
相关地，标准库是一个 all or nothing deal（技术上也有 liballoc）。除了有一个更细化的版本管理解决方案外，更细化地使用标准库，而不仅仅是核心库或所有的标准库，也是有益的。
Rustc 现在是一个非常庞大的软件。它有很多固有的复杂性（Rust 是一种复杂的语言，在快速编译的同时提供良好的错误信息是非常困难的），很多大型软件的常见问题以及大量的技术债务。存在一些重大挑战，尤其是在编译时间方面（其中增量编译和并行编译是两种正在进行中的方法），而这些都被证明是难以实现的工作；未来想要做出重大改变只会变得更加困难。幸运的是，编译器团队有能力、精力充沛且资源充足。但是，要对 rustc 进行大的、高影响的更改仍然具有挑战性。
Macros 是语言中最不完善的部分之一。Declarative macros 引入了一种全新的子语言；Procedural macros 则很笨重，需要大量依赖并且难以掌握。所有的宏都与编译器（编译时间、增量编译、错误信息）和工具（IDEs、rustdoc 等的各种问题）配合得很差。
“我认为这是一个巨大的挑战（而不仅仅是另一个可以处理的语言特性）的原因是，这些问题是分散的和困难的。（可能）没有良好的解决方案，只有大量的工程和设计工作。许多问题（例如，macro hygiene）需要社区中不存在的专业知识。宏的优先级也不够高（毕竟它们本质上是有效的），也没有足够的魅力来吸引贡献者。”
Nick 最后总结称，他列出了十个所谓 “大” 的 Rust 问题，可能会让人感觉有点消极；但这确实都是现实中所面临的挑战。幸运的是，项目内部的人都知晓这些问题的存在，并在积极地解决中。
“尽管任何解决方案都很困难，但我认为所有这些挑战都有可行且现实的解决方案。如果我们能够专注于解决这些问题（当然还有其他所有的日常挑战），那么我认为 Rust 将继续发展并取得成功。”
详情可查看博客全文：https://www.ncameron.org/blog/ten-challenges-for-rust/
Cloudflare弃用Nginx，改用内部Rust编写的Pingora
点这里 ↓↓↓ 记得 关注✔ 标星⭐ 哦~
文章评论