Rust Lang 2024 年路线图：拉平学习曲线、扩大规模

本文最初发布于Inside Rust Blog，由 InfoQ 中文站翻译并分享。

注意：这篇博文是https://lang-team.rust-lang.org/roadmaps/roadmap-2024.html上路线图的快照，原版本中可能会有后续更改，但在这篇博文中不会。请访问该页获取最新版本。

Rust 1.0 于 2015 年发布，从那时起，我们见证了 Rust 从一种用于少数几个著名项目的小型语言发展为几乎所有大型科技公司的主流语言。

当我们朝着 Rust 2024 迈进时，很自然地会问这门语言的下一个目标是什么，这个路线图通过描述我们 Lang 团队和 Rust 团队成员优先考虑的事情，来明析这个问题。

关于这个路线图，我们有两个目标：

• 让人们了解未来几年，Rust 会发生什么

• 为那些愿意为 Rust 做贡献的人提供帮助，如何参与“起点”，以及了解我们正在寻找什么样的项目

另请参阅Rust编译器2022的雄心壮志，了解 Rust 编译团队的计划，观看 Inside Rust 博客，从 Rust 库团队了解即将推出的路线图。

Rust 2024：扩展授权

Rust 的目标是让每个人都能够构建可靠和高效的软件。成功不仅需要设计和实现拥有优秀库和优秀工具的优秀语言，还需要维护一个优秀的支持社区。

我们在 Rust 2024 的重点是通过许多不同的方式扩大授权，随着我们的成长，面临越来越多的挑战，即我们如何将受权的方式扩展到越来越多的人，这个路线图展示了我们计划关注的三个主题：

• 拉平(学习)曲线：扩展新用户和新用例

• 让新用户和现有用户更容易使用 Rust，并使解决难题变得更容易。

• 帮助Rust的用户互助：扩展生态系统

• 授权给库作者，他们可以反过来授权给他们的用户。

• 帮助Rust项目扩大规模：扩大项目

• 在开发流程上要适应越来越多用户的需求和用例；评估并完成我们已经开始的项目。

对于每个主题，我们将详述对 Rust 2024 的目标，并举例说明目前正在做的事情，以及我们在未来几年想要做的事情。

这个路线图是一个起点，我们的目的是突出那些将对 Rust 的成功产生最大影响的领域。具体的例子会随着时间的推移而改变，无论是因为它们完成了，还是因为新的提案出现。随着 2023 年的临近，我们将重新审视这些主题，看看我们取得了多少进展，以及我们是否希望调整清单。

主题：拉平(学习)曲线

愿景

由于对人体工程学的一贯关注，Rust 在过去几年已经变得相当容易使用。建立大型 Rust 团队的公司报告称，Rust 工程师的入职时间通常在 3-6 个月左右，一旦人们学会了 Rust，通常会喜欢上它。即便如此，许多人报告说在使用 Rust 时感觉“认知开销”很高，“学习曲线”仍然是不使用 Rust 的最常见原因。事实上，即使在你了解 Rust 的借用检查器的工作原理后，仍然有许多“小细节”需要你正确地处理，才能编译 Rust 程序。

对于 Rust 2024，我们将识别并消除许多必须学会使用 Rust 的模式和特质；我们的目标是让你直接关注问题域的“内在复杂性”，并尽可能避免 Rust 的“偶发复杂性”。

异步和嵌入式 Rust 是我们特别感兴趣的领域，在支持这些领域方面已经取得了很大的进展，而且它们正在迅速增长。尽管如此，Rust 缺乏许多核心功能，这些功能不仅使 Rust 为这些领域工作成为可能，而且简单和令人愉快。在 Rust 2024 中，我们将缩小这些差距。

为了实现这一愿景，我们的计划是聚焦于四个高层次目标(由广义到精确)：

• 更精确的分析，更少的繁琐：通过对借用检查器、类型推断等的改进，使编译器能够更好地识别代码何时正确。识别并消除“样板”模式，比如必须到处复制粘贴相同的 where 子句集。

• 更轻松地表达自己：在必要时扩展语言，方便你可以更直接地表达你所期望的代码执行操作。在某些情况下，采取了语法糖的形式(例如let-else)，但在其它情况下，这可能意味着扩展类型系统以能够描述新模式（例如泛型关联类型）。

• 改进异步支持：将我们的 async-await 支持扩展到当前的“MVP”之外，包括 traits 中的 async fns、async drop 等特性，以及支持异步愿景文档路线图所需的其他特性。

• 让 dyn Trait 更有用：增加可以与 dyn 一起使用的 Trait 的集合，使 dyn 更接近于泛型使用。

如何提供帮助

加入 rust-lang Zulip，或者在#t-lang/roadmap-2024上发贴；如果你想先私下讨论，可以发送信息给 nikomatsakis。

计划（到目前为止）

当前每一个类别中积极举措包括：

• 更精确的分析，更少的冗余：

• 非词汇的生命周期是向前迈出的一大步，但polonius项目承诺将进一步提高借用检查的精度。

• 隐含边界承诺删除大量复制粘贴的 where 子句。

• 更轻松地表达自己：

• let-else直接表示“匹配这个变体或 return / continue /etc”模式。

• let-chains允许你使用一系列模式匹配和条件来表示迭代优化。

• "Type alias" impl Trait允许 API 命名以前无法命名的类型，这是扩展impl Trait能力的一部分。

• 泛型关联类型允许 trait 表达大量的模式(比如“可迭代”)，而这些模式是当前 trait 系统无法处理的，它们是异步编程的一个特别重要的基础部分。

• 改善异步支持：

• 我们正在努力在traits中支持asnyc fns，包括静态调度和动态调度。

• 让 dyn Trait 更有用：

• Dyn upcasting coercion Initiative：允许 dyn trait 对象从 &dyn Subtrait 向上转换到 &dyn Supertrait 。

• traits中的asnyc fn扩展了 dyn trait 以支持 asnyc fns 和“return position impl trait”。

期待

从正在进行的项目来看，还有很大的改进空间，以下是我们希望看到的其它想法。对于这些想法，他们需要的主要内容就是拥有自己的设计！如果你有兴趣尝试一下，请到#t-lang/roadmap-2024进行讨论，或发私信给 nikomatsakis。

• 更精确的分析，更少的冗余： 

• 解引用模式：允许匹配类型时使用可以解除引用的模式，比如用一个 "str" 匹配一个 String 。 

• 完善派生：基于结构字段的类型确定泛型类型参数的精确条件。例如， #[derive(Clone)] struct MyStruct(Rc<T>) 不需要 T: Clone ，因为 Rc<T> 可以在没有它的情况下克隆。 

• 自动引用、操作符和克隆：对引用进行操作的泛型方法有时需要像 &u32 ；这样的类型；因为 u32 是 Copy ，所以我们可以自动把它变成一个引用。在添加更多产生引用的操作方法时，我们曾经有些犹豫，因为它可能导致用户不期望的类型(例如 &&&str )。我们有一些想法可以简化这些情况，避免不必要的双重引用。

• 更轻松地表达自己： 

• 生成器，允许用户使用自定义语法编写迭代器(异步或其它)。

• 改善异步支持： 

• 在 trait 中添加 async fn 之后，我们打算添加对 asnyc drop、asnyc closures，和其它潜在特性的支持。

• 让 dyn Trait 更有用: 

• 使更多的模式“对象安全”，从而在 dyn Trait 对象中可用，包括通过 self 传值和在参数位置处理 impl Trait （更多信息请查看这篇文章）。

主题：帮助用户互助

愿景

Rust 结合了所有权和借用、低级系统控制以及强大的可扩展性机制(如过程宏)，使它成为编写库的绝佳语言。而且，多亏了 Cargo，在程序中使用库只需要几行代码。尽管如此，库作者还是有很多事情不能做，或者不容易做——例如，他们不能控制你看到的错误消息，或者部署需要特殊选择才能使用的“不稳定”特性。对于 Rust 2024，我们希望通过帮助管理功能的生命周期或扩展库的功能，来构建能够让库作者们更好地服务他们的用户的特性。

我们鼓励大家在库生态中进行实验和探索，构建新的功能供人们使用。有时，新功能会成为其他人构建的基础，标准化可以简化进一步开发，让循环在另一个层次上继续。然而，Rust 语言的某些方面（特别是一致性）使扩展 Rust 标准库或来自不同库的 crate 变得困难，从而阻碍了实验；其他特性（例如方法解析方面），使得很难将一流的功能提升至标准库或成熟的 crate 中，而不破坏最早开发出该功能的 crate 的用户。对于 Rust 2024，我们希望追求更多的变化，在生态系统中进行更多探索，并且能把生态系统中的代码稳定地迁移至标准库中。

为实现这一愿景，我们计划集中开展四类工作：

• 特性生命周期：帮助库作者从实验到最终确定的过程中提供支持功能，帮助库作者管理他们的开发生命周期和演进。

• 更丰富的抽象：扩展语言让库作者表达更丰富的抽象。

• 定制开发体验：许可库作者可以定制开发体验，例如，当 traits 没有实现时，可以定制用户得到的错误信息，或者引入定制 lint。

• 互操作性：库生态系统可以轻松地进行协调，使库与库之间能够协同工作，而无需捆绑；库作者可以根据自己的喜好编写跨多环境移植或特定于一种环境的代码。

如何提供帮助

加入 rust-lang Zulip，或者在#t-lang/roadmap-2024上发贴；如果你想先私下讨论，可以发私信给 Josh Triplett。

计划（到目前为止）

每一类的当前积极行动包括：

• 功能生命周期：

• RFC 3240 提出了基于版本的方法消除歧义，以支持将扩展方法从外部 crate 移至标准库中。

• 更丰富的抽象：

• Rust 的类型系统有许多核心扩展，可以开发出更丰富的特性。通常这些功能的缺乏会阻止人们编写通用的库，因为它们不能得到充分的复用：

• 在traits中async fn
  

• 常量泛型和常量评估
  

• 类型别名impl Trait
  

• 泛型关联类型
  

• 定制开发体验：

 我们目前没有在这方面采取任何协调行动，尽管有一些正在进行的努力有助于为此奠定基础。

• 互操作性：

• 支持“全局功能”，比如分配器或异步运行时，可以通过如RFC 2492之类的方法，也可能扩展到诸如作用域上下文和功能之类的事物

• 通过允许 crate 显示式声明给定类型永远不会实现给定特征，一致性中负impls允许在一致性检查中具有更大的灵活性。

• 异步工作组的可移植性倡议（建立在支持 async fn in traints 的工作之上）将通过支持更多的互操作性来帮助异步生态系统的发展。

期待

从正在进行的项目来看，还有很大的改进空间，以下是我们希望看到的其它想法。对于这些想法，他们需要的主要内容就是拥有自己的设计！如果你有兴趣尝试一下，请到#t-lang/roadmap-2024进行讨论，或发私信给 Josh Triplett。

• 功能生命周期：

• 所有的生态系统 crates 都可以有“发布火车”，相当于需要稳定性选择加入的“夜间特性”，需要一个稳定的选项。顶级 crates 保留了对其依赖项是否可以使用夜间特性的控制。

• 更丰富的抽象：

• 允许库实现 Fn 特征来定义可调用对象。

• 可变元组和可变泛型将解决“为任何元组实现此特性”的共同痛点

• 定制开发经验：

• 允许库为用户提供自定义 lint。

• 允许库控制或自定义 Rust 诊断，特别是特征解析失败。

• 互操作性：

• 恢复停滞不前的可移植性lint，或者寻求另一种设计(最近的一个建议是，“平台”可能是一个全球性的服务，类似于RFC 2492，允许人们使用 where 子句来指定可移植性代码)

• 一致性规则使得互操作性特征难以实现；我们应该找到一种方法，在保持一致性的主要好处的同时，解除这种限制。

• 采用一种标准的方法来编写性能基准测试(也许只是 criterion 正式采用)。

• 对动态链接的更好支持，具有比 CABI 更丰富、更安全的类型。例如，实现 extern “safe” ，提供 Rust 丰富类型的子集。

主题：帮助 Rust 项目扩大规模

愿景

Rust 回购是一场暴风雪活动。这很好，但它可能会让人不知所措，特别是当你试图弄清楚一些感兴趣或想做贡献的特定事情的状态时。

为了发布 Rust 2024 和让 Rust 发挥所能，我们需要一个系统，让人们更容易地了解当前进展，以及可以如何提供帮助。我们希望通过委托、授权开发者来扩展我们的语言开发，让开发者拥有并推动他们热爱的工作。Lang 团队的联络人和频繁的参与检查有助于确保质量、稳定性和整体一致性。团队本身将有一个明确的“会员之路”，帮助我们维持会员资格，并确保我们拥有所需要的专业知识。

为了实现这一愿景，我们计划集中开展三类工作：

• 一目了然：我们希望能够很容易地识别 lang 团队正在积极地开展哪些工作和进展；我们希望每个跟踪问题都能清楚地确定需要哪些“下一步”来推动特定功能的完成，并确保这些步骤为潜在贡献者清楚地记录下来。

• 明确的所有者和明确的沟通：Rust 以共识来运作，但并不意味着每个人都必须知道所有事情的所有细节。我们需要一个系统，它对要完成的工作都有明确的所有者，理想情况下，所有者不在 lang 团队。虽然简单的分工可能会导致后面的冲突，所以我们也需要经常沟通和更新，以确保每个人都能及时了解事情的整体发展方向，并尽早发现问题。

• 具有工具支持的高效、开放的流程：我们一直在寻找方法来改进操作方式，以帮助我们掌握 Rust 项目中正在进行的事项并更快得出结论。我们注意到一件事，由机器人或其它工具支持的流程往往工作得更好。

如何提供帮助

加入 rust-lang Zulip，或者在#t-lang/roadmap-2024上发贴；如果你想先私下讨论，可以发私信给 Josh Triplett 和 nikomatsakis。

计划（到目前为止）

当前每一个类别中积极举措包括：

• 一目了然：

• 计划项目委员会跟踪当前我们关注的所有活跃计划，对于每一个，都清晰地显示了当前阶段，以及他们的所有者和lang团队的联络人。

• 在待办事项会议期中，我们会讨论每一个旧的跟踪问题，并明确哪些工作需要推进（需求总结，需求设计工作，等等)。

• 我们正在花时间稳定人们正在使用的功能，并删除不完整的功能和人们不用的功能，最终的目标是将所有开放的功都视为“正在运行的”，而不是“未知的”。我们还将减少正在进行的特性总数。

• 明确的所有者和明确的沟通:

• 计划系统为每个任务分配一个所有者，他负责推进设计；还有一个 lang 团队的联络员，他帮助与团队保持一致；需要更多的工作才能使这个系统顺利运行。

• 我们将成立一个正式团队，负责确保 Rust 的类型的健壮性，并深入研究细节；这有助于培养领域专业知识的人员，同时如果有需要可以让 lang 主团队提供咨询服务。还允许主 lang 团队根据需要提供咨询。

• 具有工具支持的高效、开放的流程：

• 我们设计了一个新的共识决策过程，旨在克服 rfcbot 的一些缺点。它的实施将有助于我们更容易地做出可逆转的决定，进行更多的试验，更顺畅地提出和解决问题，还可以跟踪潜在问题从提出到稳定的整个过程。

期待

从正在进行的项目来看，还有很大的改进空间，以下是我们希望看到的其它想法。如果你有兴趣尝试一下，请到#t-lang/roadmap-2024进行讨论，或发私信给 Josh Triplett 和 nikomatsakis。

• 一目了然：

• 找到将旧的跟踪问题与积极的举措相结合的方法；减少与项目看板同步的手工更新。

• 提高项目和障碍的可视化，这样更引人注目，也更容易遵循。

• 明确的所有者和明确的沟通：

• 除了类型系统之外，在其他领域组建专门团队也是有用的。

• 具有工具支持的高效、开放的流程：

• 全面改善 rustbot，提高会议效率。

• 改进并自动化从计划提案到跟踪计划的过程。

结论

我们希望这篇文章能让你对我们计划在未来几年重点关注的内容有所了解。如果你想帮助我们实现这些目标，请参与进来！我们为每一点列出了许多积极的举措，也包括了许多寻找所有者的想法。无论你是喜欢编码、设计、编写文档还是组织，都有工作要做。如果你想对 Rust 2024 做的唯一一件事就是使用它，我们也同样欢迎。祝大家玩得开心！

原文链接：Rust Lang Roadmap for 2024