规划 2021 年路线图

2020 年 9 月 3 日 · Rust 核心团队

核心团队已开始考虑 2021 年路线图，我们希望听到社区的意见。在接下来的几周内，我们将进行两项并行工作：2020 年 Rust 调查（将在下周公布）和博客文章征集。

博客文章可以包含与 Rust 相关的任何内容：语言特性、工具改进、组织变更、生态系统需求——所有内容都在范围内。我们鼓励您尝试确定您的建议所适合的主题或广泛领域，因为这些有助于指导整个项目。

帮助我们了解您看待 Rust 的视角的一种方法是给出以下形式的陈述（一个或多个）："作为 X，我希望 Rust 能够 Y，因为 Z"。这些陈述可以提供您在文章中提出的项目的动机。以下是一些示例：

  • "作为一名日常 Rust 开发人员，我希望 Rust 能够改善使用库的体验，以便我可以更轻松地利用生态系统"
  • "作为一名希望发展利基市场的嵌入式开发人员，我希望 Rust 能够简化端到端的嵌入式开发，以便新手能够更轻松地入门"

今年，为了确保我们不会错过任何内容，当您撰写文章时，请将其提交到 此 Google 表格！我们也会尝试查看未通过此表格提交的文章，但通过此表格提交的文章不会被遗漏。任何平台（从博客到 GitHub gist）都可以！我们计划在 10 月 5 日关闭表格。

为了让您了解即将到来的年份，我们为 2020 年制定了这些高级目标，并且我们想回顾一下今年上半年。我们取得了一些重大进展！

  • 为可能的 Rust 2021 版做好准备
  • 跟进正在进行的设计和工作
  • 改进项目运作和治理

为可能的 Rust 2021 版做好准备

现在有一个 开放的 RFC 提出了 2021 版的计划！已经进行了相当多的讨论，但我们希望在接下来的 6 周内将其合并。该计划是让新版本比 Rust 2018 的范围小得多。预计它将包括一些小的调整以改进语言可用性，以及提升各种版本习惯用法 lint（例如要求使用 dyn Trait 而不是 Trait），以便它们将“默认拒绝”。我们相信我们有望在 2021 年发布一个版本。

跟进正在进行的设计和工作

我们 2020 年的目标之一是推动“正在进行”的设计工作完成。我们在这方面看到了很多努力

  • 内联汇编 RFC 已 合并，新的实现已准备好进行实验
  • 过程宏已在大多数位置稳定 自 Rust 1.45 起
  • 有一个关于 const 泛型的 MVP 的提案，我们希望在 2020 年发布
  • 异步基础小组预计很快会发布关于 Stream 特性的 RFC
  • FFI unwind 项目小组正在解决一个长期存在的健全性漏洞，并且 第一个 RFC 已合并
  • 安全 transmute 项目小组已提出 草案 RFC
  • 特性工作组正在完善 Chalk，准备 rustc 集成，并在 rust-analyzer 中看到实验性使用。您可以在 他们的 博客 文章 中了解更多信息。
  • 我们正在将 rust-analyzer 作为官方 Rust IDE 解决方案进行过渡，并有一个 合并的 RFC 概述了该计划
  • Rust 的层级系统正在被正式化，并在 正在进行的 RFC 中设定了保证和预期
  • 编译器性能工作仍在继续，在我们的许多基准测试中，性能提升了 10-30%
  • 读取未初始化的缓冲区有一个开放的 RFC，解决了 Rust 中 I/O 的另一个长期存在的问题
  • 一个关于 std 中可移植 SIMD 的项目小组提案有一个开放的 RFC
  • 一个关于错误处理人体工程学的项目小组提案，重点关注 std::error API，有一个开放的 RFC
  • std::sync 模块更新处于头脑风暴阶段
  • Rustdoc 对文档内链接的支持 即将稳定！

Rust 团队内部也进行了许多其他工作，但这些项目突出了 Rust 团队正在积极处理的一些问题和设计。

改进项目运作和治理

另一个目标是记录和改进我们运行项目的流程。我们有三个主要子目标。

提高对计划和设计工作状态的可见性

Rust 团队正在转向使用 项目小组 进行探索性工作，旨在创建专门的小组，这些小组可以探索某个领域，提出设计并将其贯彻执行。语言团队已经启动了 安全 transmute、FFI unwind 和 内联汇编 项目小组。所有这些都取得了巨大成功！其他团队也希望使用这种模式。

编译器团队已开始发布 每周性能分类报告，以持续努力减少编译时间。LLVM 工作组也一直在帮助突出显示 LLVM 本身 的性能回归，以减少更新 LLVM 时出现的编译时间性能回归。

编译器团队 引入了 重大变更提案 作为一种向实现引入较大变更的方法，在实现工作开始之前提出设计问题。语言团队 也正在尝试使用 类似的流程 来快速获得语言团队对提案的反馈，并可能形成项目小组。这些都提供了对所提议变更的高级视图，让感兴趣的各方可以跟踪这些变更，而无需订阅我们非常繁忙的存储库。

增加指导、领导力和组织带宽

  • 语言团队已经确定了一条供贡献者加入团队的路径，其中包括参与和领导项目小组工作。有关更多详细信息，请参阅 他们的文章。
  • 治理工作组一直在将现有流程正式化为 RFC，例如 项目小组 RFC、访问策略 RFC 等。
  • 库团队在治理工作组的帮助下，率先起草了团队的正式 章程。

使设计讨论更有效率，不那么令人筋疲力尽

这里的主要工作是项目小组，到目前为止，这些小组在很大程度上取得了成功。我们预计将来会在这方面做更多工作。