为了帮助实现我们2017 年的 Rust 愿景，Rust 各子团队正在针对特定的路线图目标启动各项倡议。本文介绍了库团队的主要倡议：将 Rust crate 生态系统的坚实核心提升到一致的完整性和质量水平。这项工作部分借鉴了我们在构建 Rust 标准库时学到的经验，最终将形成一份“菜谱”，其中充满了常见任务的现成示例，取材于精心挑选的 Rust crate。

（另外，如果你还没看到：请参与Rust 现状调查；即使你不使用 Rust，我们也希望听到你的声音！）

内置电池？

如果没有易于查找和使用的库，你将无法高效地使用一门语言。当然，最容易找到的库是标准库，许多语言都采取了“内置电池”的方法，直接在标准库中包含了广泛任务的 API。这样做有很多好处：这意味着只需在一个地方查找常见任务，API（希望！）在不同任务间保持一致，生态系统内部兼容，并承诺库的维护。有什么不好呢？

有一种相反的观点，最尖锐的说法是“标准库是代码走向终结的地方”（这是对“内置电池”式标准库的常见抱怨）。因为标准库与语言本身耦合，它的发布频率与语言相同，进行破坏性更改意味着破坏整个语言。由于这些原因以及其他原因，标准库往往保守地演进。

就像在 Rust 世界中常见的那样，我们的目标是鱼与熊掌兼得。我们能否提供一种类似“内置电池”的体验，同时又不让这些代码在标准库中固化？这对 Rust 来说是一个尤其重要的问题，因为作为一个社区，我们仍在快速探索和迭代基于所有权的 API 设计的最佳实践。

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

因为有 Cargo，我们可以“包含电池”而无需将其字面意义上放入标准库；拉取其他 crate 几乎与使用标准库一样容易（今年可能会变得更简单）。但要充分利用这种能力，我们需要拥有出色的库。我们 2017 年的任务是确保有广泛的常见任务所需的 crate，并且它们是可发现的、一致的、功能丰富的和文档完善的。

The Rust Libz Blitz

幸运的是，虽然标准库保持小巧和专注，但 crates.io 生态系统一直在以惊人的速度增长。因此，这里的挑战不是从零开始的库工作。更多的问题是：Rust 社区如何集中精力，打磨、整合和凸显一套用于基本任务的核心库？我们的答案是 Rust Libz Blitz。

基本思路是

• 在共享论坛中集体审查少量 crate。审查部分参考了一套API 指南。
• 每两周，举行一次库团队会议，重点讨论围绕其中一个 crate 的未解决问题，并邀请作者参加。
• 将反馈意见推送到该 crate 的跟踪问题中，并引导 Rust 社区前往协助承担改进工作。
• 为每个 crate 在新的 Rust Cookbook 中编写条目，这将有助于发现 crate 并快速开始使用它。

Rust 库团队在过去几个月里一直在悄悄地进行这项工作，以理清各种细节。但现在，我们希望将其开放给整个 Rust 社区。在本文的其余部分，我们将更深入地探讨这一过程的机制和目标。

Rust 的质量标准

在标准库的所有工作中，我们已经对如何设计出色的 Rust API 有了认识：诸如“使性能特征清晰”和“使用所有权来封装不变量”等原则；诸如 `mut`、`ref`、`as`、`into` 等一致的命名约定，使用户可以从已知推断未知；许多累积起来的展示细节，例如在专门的“错误”部分持续记录可能的错误情况；以及发布 Rust crate 时需要考虑的更多因素。

在 2017 年，我们计划将 `std` 设计背后的原则应用于日益广泛的关键 Rust 库基础。在此过程中，我们将记录我们关于 Rust 库设计的经验教训。

这个过程的产物将是一套成熟的核心库，以及一套API 指南，Rust 作者可以遵循这些指南来深入了解 Rust 的设计并提升他们自己感兴趣的 crate 的质量。今天这些指南仍处于非常早期阶段，但可以让你了解我们这项工作的方向。请查阅并在不清楚或缺失的地方提交 issues！

Rust 的文档标准

我们最近进行了一项小型调查，了解 Rust 程序员在评估一个 crate 时最关心什么。迄今为止，最常见的标准是文档。因此，Libz Blitz 过程的一个重要部分将是评估和改进目标 crate 的文档，这将补充正在进行的重写 Rust Book 和为标准库提供全面的示例的工作。API 指南中包含专门关于出色文档的部分，我们的目标是确保所有核心 crate 具有一致、易于导航的文档体验。

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

Libz Blitz 为每个 crate 所做的工作之一是确定该 crate 试图解决的关键问题，并为每个问题在 Cookbook 中添加有力的示例。

Rust 的可发现性标准

也许标准库小巧的最大缺点是可发现性问题：当 Rust 程序员需要完成标准库未涵盖的任务时，他们如何知道去哪里寻找？

上面提到的 Cookbook 无疑将成为我们答案的主要部分。但与此同时，我们希望确保有新 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 指南。

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

根据评估和库团队的审查，我们将提出在我们看来在发布 crate 稳定版本之前必须解决的问题。我们希望这些问题中有许多适合随意贡献。

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

• 添加一个超级 trait 来隐藏 trait 细节
• ByteOrder::default 应该 panic! 而不是 unreachable!
• 将 panic 和 error 文档放在“Panics”和“Errors”部分
• 确保有足够的示例
• 在 Cargo.toml 中添加 CI 徽章
• 在 Cargo.toml 中添加“categories”
• 添加 #[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 需要一个志愿者来领导评估工作。这包括发起一个帖子，将评估工作分解成小的、社区其他人可以承担的工作项，保持讨论朝着富有成效的方向发展，确保评估按时完成，在库团队会议上展示结果，最后，针对所有提出的问题提交具体、可操作的 issue，并将它们汇总到 TWiR。

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

• Crate 评估人。这是将 crate 与 API 指南进行比较、找出不足之处并提出可能影响指南的 API 设计观察结果的初步工作。这通常需要与 crate 作者合作，以了解 crate 已知的缺点。

  每项评估结果都将发布到协调帖子中，供大家提供反馈。开放反馈允许听到各种声音，是防止设计近视的重要制约。

  这项工作是协作性的，欢迎任何人随时以这种方式参与。Crate 负责人将协助创造参与机会。

• 文档撰写者/贡献者。将 crate 提升到完整质量水平的大量工作是改进文档，包括撰写 cookbook 条目。将有很多机会进行这种高价值的工作。

  欢迎任何人随时以这种方式参与。Crate 负责人将协助创造参与机会。

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

  欢迎任何人随时以这种方式参与。Crate 负责人将协助创造参与机会。

• 库设计师。仍然有一些重要的库维护较少，但已知需要进行大量设计工作（再次特别想到 rand）。如果没有专注且熟练的作者推动它们前进，这些库就不会改进。我们将寻找具有解决问题所需的设计技能和驾驭过程所需的社交技能的作者。

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

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

  这将是受邀参加的，重点是那些在高质量工作和富有成效的协作方面已有声誉的作者。

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

TL;DR（太长不看）

计划如下

• 我们将直接改进您每天使用的最重要的 crate。
• 我们将以API 指南的形式，为 crate 作者提供他们所需的指导。
• 我们将创造源源不断的易于参与的贡献机会，直接有助于实现关键的 Rust 战略目标。
• 我们将以crate cookbook的形式，为如何使用 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。