为了帮助实现我们Rust 的 2017 年愿景，Rust 子团队正在发起针对特定路线图目标的倡议。这篇文章涵盖了库团队的主要倡议：将 Rust crate 生态系统的坚实核心提升到一致的完整性和质量水平。这项工作部分受我们在生产 Rust 标准库中所学到的知识指导，并将产生一个“食谱”，其中充满了常见任务的现成示例，这些示例来自对 Rust crate 的精心选择。

（另外，ICYMI：请参与Rust 状态调查；即使您不使用 Rust，我们也希望听到您的意见！）

内置电池？

如果找不到易于查找和使用的库，您就无法在某种语言中高效工作。当然，最容易找到的库是标准库，许多语言都采用了“内置电池”的方法，该方法直接在标准库中包含用于广泛任务的 API。这样做有很多好处：这意味着只有一个地方可以查找常见任务，API（希望！）在任务之间保持一致，整个生态系统具有兼容性，并承诺库的维护。有什么不喜欢的？

有一种相反的思维方式，用最严厉的说法是“标准库是代码走向死亡的地方”（有时会听到对内置电池的标准库的抱怨）。由于标准库与语言本身耦合在一起，因此它的发布频率与语言相同，并且进行重大更改意味着破坏整个语言。由于这些原因和其他原因，标准库往往会保守地发展。

与 Rust 世界中的惯例一样，我们的目标是鱼与熊掌兼得。我们是否可以在不将代码固化到标准库中的情况下提供类似内置电池的体验？对于 Rust 来说，这是一个特别重要的问题，因为作为一个社区，我们仍在快速探索和迭代基于所有权的 API 设计的最佳实践。

我们方法的关键要素是 Cargo，它是在 Rust 1.0 中发布的包管理器，并且一直在改进。Cargo 在整个 Rust 生态系统中提供了一个统一的依赖关系和工作流，并且可以轻松且相对低风险地添加依赖项。轻松共享代码的能力是对传统系统编程任务的特性和受众的强大改变。

由于 Cargo，我们可以“内置电池”而无需将它们实际放入标准库中；引入其他 crate 几乎与使用标准库一样容易（并且今年可能会变得更容易）。但是，为了充分利用这种能力，我们需要有出色的库。我们 2017 年的任务是确保有 crate 可用于广泛的常见任务，并且它们是可发现的、有凝聚力的、功能丰富的和文档齐全的。

Rust Libz 闪电战

幸运的是，虽然标准库一直保持小巧和专注，但 crates.io 生态系统一直在以惊人的速度增长。因此，这里的挑战不是新建库的工作。更多的问题是：Rust 社区如何以集中的方式工作，以抛光、整合和突出用于基本任务的核心库集？我们的答案是 Rust Libz 闪电战。

基本思路是

• 在共享论坛中集体审查一次几个 crate。审查部分借鉴了一组 API 指南。
• 每两周举行一次库团队会议，重点讨论围绕其中一个 crate 的未决问题，作者将出席会议。
• 将此反馈推送到 crate 的跟踪问题上，并指向 Rust 社区以帮助承担改进的负担。
• 在新版 Rust 食谱中为每个 crate 编写条目，这将使其易于发现 crate 并开始使用它。

Rust 库团队在过去的几个月中一直在悄悄地参与此过程，以理清问题。但是现在，我们想向整个 Rust 社区开放它。在本文的其余部分中，我们将更深入地探讨此过程的机制和目标。

Rust 质量标准

在标准库的所有工作中，我们已经了解了什么使 Rust API 变得出色：诸如“使性能特征清晰”和“使用所有权来封装不变式”之类的原则；一致的命名约定，例如 mut、ref、as、into，让用户可以从他们所知道的内容中直观地了解他们不知道的内容；演示的小细节加在一起，例如在专门的“错误”部分中一致地记录可能的错误情况；以及发布 Rust crate 时要考虑的更多因素。

在 2017 年，我们计划将 std 背后的设计原则应用于不断扩大的关键 Rust 库的基础。在此过程中，我们将记录我们学习到的有关 Rust 库设计的知识。

此过程的成果将是一个成熟的核心库以及一组 API 指南，Rust 作者可以遵循这些指南来深入了解 Rust 的设计并提高他们自己感兴趣的 crate 的水平。今天，这些指南还处于非常早期的状态，但是可以让您了解我们在这项工作中的进展方向。查看一下并提出问题，说明哪些内容不清楚或缺失！

Rust 文档标准

我们最近进行了一项小型调查，以了解 Rust 程序员在评估 crate 时最关心什么。最常见的标准是文档。因此，Libz 闪电战过程的重要组成部分将是评估和改进目标 crate 的文档，这将补充正在进行的 重写 Rust 书籍并为标准库提供全面的 示例的努力。API 指南包含专门介绍出色文档的部分，我们的目标是在所有核心 crate 中提供一致且易于浏览的文档体验。

除了 crate 本身中的文档（它往往更具有“参考”风格）之外，我们还正在启动一个 Rust 食谱，它将围绕您想要解决的问题进行组织，并提供您可以直接放入项目中的快速、具体的示例代码，这些示例代码来自各种 crate（包括标准库）。像这样的示例是快速高效地使用库的最有用的工具之一，并将它们全部收集在一个地方，按问题组织，将有助于我们在使用 Rust 时获得“内置电池”的体验。

在 Libz 闪电战中为每个 crate 完成的部分工作将是确定 crate 试图解决的关键问题陈述，并为食谱中的每个问题添加有力的示例。

Rust 可发现性标准

拥有小型标准库的最大缺点也许是可发现性问题：当 Rust 程序员需要执行标准库未涵盖的任务时，他们如何知道在哪里查找？

上面提到的食谱无疑将成为我们答案的主要部分。但与此同时，我们希望确保有新 crate 出现的地方，并且人们可以轻松找到超出最常见问题区域的 crate。为此，我们正在正面解决可发现性问题，方法是在 crates.io 上推出各种质量指标的徽章，并大大改进结果的默认排名（通过 RFC 激烈辩论的设计）。这里有大量的工作空间，因此如果您有关于进一步改进 crates.io 可发现性的想法，请启动一个主题！

Rust 社区标准

我们对发布出色的 Rust crate 有一些了解，但是 Rust 库团队不是 Rust API 设计的唯一权威机构 - Rust crate 生态系统是由我们所有人共同创建的，还有很多经验要学习。认识到这一点，库团队正在设计我们的努力，使其尽可能欢迎和包容。

我们将启动论坛讨论，以评估我们认为对走上稳定之路至关重要的现有 crate，并且这些 crate 大多需要进行润色级别的工作才能实现目标。这些评估将是协作性的，旨在公开评论。它们旨在识别使 crate 与“1.0”状态（在质量和 API 稳定性以及字面版本号方面）分离的任何问题。问题可能包括不符合 Rust API 设计原则、缺少实质性功能、计划的 API 重构、不完整的文档或任何数量的独特情况。

我们将同时进行少量的此类评估。每两周，库团队将在我们的定期视频会议中讨论一项评估，该会议将被录制并在 Air Mozilla 和 Rust YouTube 频道上提供。这些会议的一个目标是为稳定相关 crate 制定路线图。另一个目标是从 crate 中找出要学习的任何经验教训，并将其提炼成广泛适用的 API 指南。

为了加强 Rust 团队与 Rust 生态系统作者之间的联系，并促进彼此之间的共同价值观，我们将邀请轮流的嘉宾（包括 crate 作者）参加视频会议。

基于评估和库团队的审查，我们将提交我们认为在发布 crate 的稳定版本之前需要解决的重要问题。我们期待许多这些问题能够通过非正式贡献来解决。

以下是从非常简单的 byteorder crate 中出现的问题（现已全部解决）

• 添加一个 supertrait 来隐藏 trait 的细节
• ByteOrder::default 应该 panic! 而不是 unreachable!
• 将 panic 和错误文档放在“Panics”和“Errors”部分
• 确保有足够的示例
• 将 CI 徽章添加到 Cargo.toml
• 将“categories”添加到 Cargo.toml
• 添加 #[doc(html_root_url)]

除了 byteorder 之外，我们已经对其他几个简单的 crate 进行了这个过程，以了解它：bitflags、tempdir、flate2 和 lazy_static。即使是这些最基础的 crate，也还有一些工作要做，但您可以期待它们很快就会发布“1.0”版本。随着评估的 crate 的范围扩大，预计出现的任务也会增加。

我们将关注哪些 crate？

Rust 有一些令人惊叹的库正在开发中：例如 tokio，它是一个非常快速的异步 I/O 框架；例如 diesel，一个用于与数据库表交互的非常快速的库；以及例如 rocket，一个非常快速的 Web 框架。

我们不会触及它们。

这些备受瞩目的库建立在数十个在整个生态系统中执行关键功能的小型 crate 之上：随机数生成、内存映射、压缩等等。我们需要完善 Rust 堆栈的底层，以便这些高级库有一个稳定的基础可以构建。

关注这些底层不仅是一个实际的考虑，也是一个技术上的考虑——一个 crate 在其公共依赖项稳定之前不应该是稳定的。考虑一下假设的 diesel 1.0 版本导出一个函数，该函数返回来自仍在快速开发的 uuid 0.5 版本的类型意味着什么。不久之后，它将与其他使用较新版本 uuid 的库不兼容。

此外，许多这些高级库本身也正在经历快速发展，并有自己的强大领导。我们不想通过在它们准备好之前迫使它们声明 crate 稳定来干预这些 crate 作者尝试其设计的权力。这些库会随着时间的推移而成熟。

但是有许多基础库已经达到相对稳定，在某些情况下功能完整并在生产中广泛使用。有些只需要少量的工作就可以完成。有些，例如 rand crate，被广泛使用，但已知其设计不令人满意。我们希望最终将这些 crate 解决掉。

我们目前通过结合 crates.io 依赖数据、各种现有的精选 crate 列表和良好的直觉来绘制此基础 crate 列表。确切的列表肯定可以讨论，我们希望更广泛的社区也会完全独立地将此过程应用于库团队没有时间讨论的 crate。

我如何提供帮助？

很高兴你问了！为一个年轻的语言创建一套坚实的库核心不是一个人或一个团队的工作，而是整个社区的工作。协调的中心点是 Rust 内部论坛上的一个主题。阅读该主题，了解我们正在做的所有细节，以及参与的持续机会。

需要你帮助的角色

• Crate 负责人。每个 crate 都需要一位志愿者来领导评估工作。这需要启动一个主题，将评估工作分解为社区中的其他人可以承担的小工作项，保持讨论朝着富有成效的方向发展，确保评估按时完成，在库团队会议上展示结果，最后，在所有提出的问题上提交离散的、可操作的问题，并将它们传递给 TWiR。

  任何人都可以成为 crate 负责人，但这需要大量投入，并且主要关于组织、沟通和共识，并且需要在视频会议中向库团队进行演示。

• Crate 评估员。这是将 crate 与 API 指南进行比较、识别缺陷以及提出可能影响指南的 API 设计的初步工作。它通常需要与 crate 作者合作以了解 crate 已知的缺点。

  每个评估都将发布到协调主题，提供一般反馈的机会。开放的反馈允许听到广泛的声音，并且是对设计短视的重要检查。

  这项工作是协作的，欢迎大家随时以这种方式参与。Crate 负责人将帮助创建参与的机会。

• 文档撰写者。让 crate 达到完整质量的许多工作都涉及到改进文档，包括编写烹饪书条目。将有很多机会进行这种高价值的工作。

  欢迎大家随时以这种方式参与。Crate 负责人将帮助创建参与的机会。

• 库黑客。必须有人完成编程工作，以解决每个 crate 的稳定性路线图上的问题。我们预计会产生许多离散的工作项，其中许多工作项对于没有经验的 Rust 程序员来说是可以访问的。

  欢迎大家随时以这种方式参与。Crate 负责人将帮助创建参与的机会。

• 库设计师。仍然有一些重要的库仅得到轻微维护，但已知需要进行重要的设计工作（再次考虑 rand 特别是）。如果没有专门且熟练的作者来推动它们前进，它们将无法改进。我们将寻找具有解决问题所需的设计技能以及驾驭流程所需的社交技能的作者。

  我们偶尔会在出现特定设计问题时发出求助请求。

• 库团队嘉宾。库团队将在他们的一个视频会议上审查每个 crate 评估。我们希望 crate 作者有兴趣加入我们，分享他们独特的专业知识，并了解库团队。这种互动以一种文字交流无法做到的方式建立了牢固的联系。我们希望这将促进整个生态系统中的共同价值观，并为更正式地扩大库团队铺平道路。

  这将通过邀请进行，并专注于在高质量工作和富有成效的协作方面具有现有声誉的作者。

• Crate 作者。库团队今年有一些特定的功能和 crate 希望关注。除此之外，我们希望我们开发的过程和指南将被广泛使用，并且 crate 作者将独立地寻求以类似的方式评估和改进他们自己的 crate。

太长不看（TL;DR）

这是计划

• 我们将直接改进您每天使用的最重要的 crate。
• 我们将为 crate 作者提供他们所需的指导，以便他们以 API 指南 的形式进行相同的操作。
• 我们将创造无休止的可访问的贡献机会，这些机会直接有助于 Rust 的关键战略目标。
• 我们将以 crate 食谱 的形式，生成关于如何使用 Rust 最基础 crate 的连贯文档。
• 我们将启动一个库改进的自我维持过程，该过程可以一致地应用于整个生态系统。

感谢迄今为止做出贡献的每个人，包括 Alisha Aneja、Andrew Gallant、Brad Anderson、Charles Chamberlain、Dan Burkert、David Harris、Jan-Erik Rediger、Peter Atashian、Roman Frołow、Sean McArthur、Simon Sapin、Stephan Buys、Steven Fackler、Trent Spice。