今年 1 月，我们采纳了 2017 年 Rust 路线图，其中概述了我们对 2017 年的计划。作为路线图流程的一部分，我们计划定期发布有关每个路线图项目进度的更新。这篇文章标志着今年年中。
通过路线图问题跟踪进度
首先，一个元说明。如果您想跟踪特定路线图计划的进度，或者想了解更多关于如何参与的信息，最好的地方是 rust-roadmap 仓库中的问题列表。在那里，您将找到一个专门针对我们正在推动的主要计划的问题。这些问题包含指向正在进行工作的链接。您将在以下描述中找到许多指向此类问题的链接。
Rust 应该有一个更低的学习曲线
使 Rust 更易于学习的最直接方法是改进我们教授它的方式。为此，我们一直在努力编写官方“Rust”书籍的全新版本 (路线图问题)，现在我们已经有了 完整的在线草稿。这个新版本将所有权放在首位，并且还扩展了对 Rust 中许多其他领域的覆盖范围，例如错误处理、测试、匹配、模块等等。更棒的是，您可以通过 No Starch Press 预订印刷版。如果您想帮忙，还有 很多编辑工作要做！
我们还一直在进行一些语言更改，旨在改进 语言人体工程学。这些范围从长期存在的提案，例如 非词法生命周期 或 impl Trait，到更新的想法，例如最近批准的关于 特征别名 和 匹配人体工程学 的 RFC。在 路线图问题 中，您将找到一个大型的计划列表，这些计划按其目标语言部分（例如，所有权/借用、特征系统等）进行组织。我们正在积极寻找人员来帮助撰写 RFC，以及实施已接受的 RFC - 如果您有兴趣帮助完成某项工作，请查看路线图问题或特定 RFC 的跟踪问题中列出的“指导”联系人。当然，如果您认为您有一个好主意，但没有列出，请在内部打开一个线程，让我们谈谈！
Rust 应该有一个愉快的编辑-编译-调试周期
我们一直在以多种不同的方式解决改进编译器性能的问题。最简单的方法之一是 我们在 Rust 1.16 中发布的 cargo check 命令 - 这个命令执行一种有限形式的编译，它跳过代码生成，只查找错误。由于代码生成通常占编译时间的 50% 或更多，因此这在您编写新代码并尝试使其编译的早期阶段非常有用，特别是如果您有一个多箱项目。此命令也被 RLS 使用。
当然，最终您需要运行您的代码，为此您需要完整的编译。为了使这更快，我们一直在努力重新设计编译器以增量方式工作。今年早些时候，我们在 nightly 构建中宣传了 “增量”的“beta”版本。虽然 beta 版本有时实现了相当大的加速，但我们也发现依赖项跟踪不像我们希望的那样健壮或有效。因此，我们现在正在采用一种新的改进的增量编译方法，我们预计它将在下个月左右准备就绪。如果您有兴趣帮助过渡到新系统，请查看 增量编译路线图问题 或 新算法本身的跟踪问题；您也可以关注 这个内部线程，我们定期发布包含指导说明的错误链接。
展望增量编译，我们也一直在采取措施以其他方式优化编译时间。在这方面，可能最重要的步骤是让 perf.rust-lang.org 网站 的新版本运行起来。“perf”网站跟踪每个 PR 对编译性能的影响，以便我们可以检测和纠正回归。事实上，新网站立即导致了一些 重大性能改进。然而，仍然有很多工作可以完成以改进它，从评估和改进我们的基准套件到改进 Web 界面；有关更多信息，请查看 关于此主题的跟踪问题。
Rust 应该提供一个可靠但基本的 IDE 体验
自从它去年在 RustConf 首次亮相以来，Rust 语言服务 (RLS) 一直在快速发展 (路线图问题)。它现在支持大多数基本的 IDE 操作，例如“跳转到定义”或“查找所有用法”，以及提供代码补全（通过 racer 项目）。目前，重点主要放在抛光上：使 RLS 更易于安装并修复错误。例如，我们最近使 直接通过 rustup 安装 RLS 成为可能。
如果您想试用 RLS，最简单的方法是使用 VSCode 插件；但是，RLS 是一个通用服务器（它使用微软的 语言服务器协议），并且还有许多其他编辑器的客户端可用。警告：目前，RLS 仍处于“alpha”阶段。虽然它非常可用，但您可能会遇到错误或其他限制。
如果您想参与 RLS，请查看 路线图问题 或 RLS 问题列表；特别是那些带有 “好的第一个问题” 标签的。
Rust 应该提供轻松访问高质量的箱子
随着 crates.io 生态系统的规模不断扩大，crates.io 网站使用的简单搜索和排序标准对于确定应该使用哪些箱子不再那么有帮助。为了解决这个问题，我们添加了 类别 和 许多徽章，箱子作者可以将其添加到他们的箱子中。这些帮助人们找到用于特定目的的箱子，并一目了然地判断箱子的质量。此外，RFC 1824 概述了改进 crates.io 中默认排序并公开更多信息以帮助选择箱子的计划。有一个 跟踪问题 列出了此 RFC 的部分内容，我们很乐意为这些部分提供贡献！一旦 RFC 完全实施，人们有机会使用这些功能一段时间后，我们计划征求社区的反馈并进行调整。
此外，下面描述的 “食谱” 工作也将有利于以任务为中心的方式发现箱子。
Rust 应该非常适合编写健壮的服务器
今年上半年，我们在使 Rust 能够编写健壮的服务器方面取得了一些重大进展。 futures 库和 Tokio 项目继续探索异步 I/O 生态系统，并通过 Hyper 等库和 linkerd-tcp 等生产用户获得了广泛应用。此外，我们还看到像 Rocket 这样的项目不断努力提高 Rust 在服务器上的可用性。最近关于当前最大障碍的 讨论 强调了 async/await 语法、更好的 Tokio/futures 文档以及生态系统中坚实的 HTTP 基础是接下来的几个优先事项。我们计划在今年年底之前在 nightly Rust 通道上启用 async/await 语法，并在 2018 年初将其稳定化。这反过来应该有助于推动 Tokio/future 文档的重写，并继续扩大社区对 HTTP 等库的支持。
Rust 应该为基本任务提供 1.0 级库
Libz Blitz 正在快速进行！Libz Blitz 是一个系统性的努力，旨在识别 Rust 生态系统中最广泛使用的库，并确保它们都达到一致的完整性和质量水平。这项工作需要在内部论坛上进行协作，根据 API 指南 审查库，提交和修复出现的错误，并为新的 "Rust 示例手册" 编写示例。
这项工作被设计成非常适合贡献，特别是来自新 Rust 开发人员的贡献，到目前为止，它已经解决了 10 个库中的 99 个库问题，并为手册创建了 30 多个示例，这要归功于 53 位贡献者的努力。
如果您有兴趣参与，请查看 内部线程上的介绍性帖子。
Rust 应该轻松集成到大型构建系统中
大多数关于构建系统集成的工作都集中在更清楚地识别挑战并制定针对这些挑战的具体提案。一些当前的探索途径是
- 支持使用 Cargo 创建构建计划但不执行它
- 支持以一等公民的方式声明外部依赖项（而不是像我们今天这样通过任意构建脚本）
我们希望在今年下半年加快这项工作，但需要您的帮助。如果您对上述任何 Cargo 改进感兴趣，或者您对构建系统集成有任何见解，请在 跟踪问题 上联系我们！
Rust 社区应该在所有级别提供指导
在指导方面，我们一直在进行一些不同的努力。第一个，RustBridge，专门针对将弱势群体带入科技领域；它也作为完全不熟悉 Rust 的人的一个很好的课程。这些材料已经经过多次迭代，并且不断发展和改进，我们将 在 RustConf 前一天举办 RustBridge 研讨会。我们希望看到更多 RustBridge 活动。
我们还刚刚推出了 扩大 Rust 的影响力，这是一个旨在从目前在 Rust（或更广泛的技术领域）中代表性不足的群体中获得更多反馈，并共同努力使 Rust 能够被更广泛的受众所接受的倡议。虽然这不是一个指导计划本身（在很多情况下，是参与者在进行教学！），但它仍然旨在降低进入 Rust 社区的门槛。
此外，各种 Rust 团队一直在进行许多不同的倡议，试图鼓励人们参与 Rust 项目本身
- 我们 增加了三个新团队——基础设施、Cargo 和开发工具——因此创造了人们可以参与的新领域。
- lang 团队采用了新的 shepherd 角色。Shepherds 是社区中经验丰富的成员，他们既展示了出色的技术能力，又展示了达成共识和理解不同观点的能力。Shepherds 参加语言会议，帮助引导 RFC 的讨论，并引导它们走向有用的结论。
- lang 团队也一直在努力“指导”RFC。例如，可用性倡议的路线图问题 列出了我们正在积极招募的几个 RFC。
- "Libz Blitz" 的一个重要部分是帮助引导社区努力将库推向完成。
- 编译器团队一直在积极地“指导错误”（标记为 E-mentor 的错误），其中包括书面说明，以及 制定计划 来改进代码和工作流程的文档。
探索领域
除了主要的路线图项目之外，路线图 RFC 还指出了两个“探索领域”。这些是 Rust 具有巨大潜力的领域，但仍处于更具探索性的阶段。
嵌入式 Rust 倡议
嵌入式 Rust 生态系统正在不断发展。针对 Cortex-M 微控制器的裸机并发 框架 针对 机器人 和 控制 系统最近被开发出来。而 Tock，一个也针对 Cortex-M 微控制器的嵌入式操作系统，一直在朝着纯 Rust 用户空间应用程序 发展，并继续扩展 其驱动程序支持。
在编译器方面，由于 社区的努力，对 MSP430 架构的支持一直在改进，而 对 AVR 架构的支持 也正在由社区在树外进行开发。
在社区方面，随着 指南、项目模板、核心库 和 工具 的创建和开发，标准化开发工作流程的努力正在进行中。最近，一项 调查 旨在识别嵌入式开发人员的当前需求，相应的 路线图问题 已更新以反映调查结果。为了响应调查结果，社区努力创建硬件抽象层，该层将作为构建嵌入式库生态系统的基础，已经 开始，并且设计 讨论 目前正在进行中。一个“我们已经嵌入了吗？”网站将反映嵌入式生态系统的最新状态并跟踪其进展，也正在 开发中。
(感谢 Jorge Aparicio 的撰写。)
与其他语言集成：bindgen 更新
C 和 C++
bindgen 是将 C 和 C++ 库自动集成到 Rust 代码库的前沿。bindgen 以头文件作为输入，并输出相应的外部函数和类型声明，以便 C/C++ 库可以以最小的努力从 Rust 中使用。
bindgen 已经成为 Stylo 项目 的关键基础设施，该项目将 Servo 的样式系统引入 Firefox。随着 Stylo 项目接近发布，我们一直在为生产环境打磨 bindgen。这表现为大量的可靠性和正确性工作。我们的测试套件不断扩展，我们一直专注于结构布局、大小和对齐的正确性，包括位域等 ABI 边界情况，以及跨不同 libclang 版本的测试覆盖率和支持。
与此同时，我们一直在努力改善 贡献体验。我们一直在记录工作流程，添加 内部表示的可视化 用于调试，并指导新的贡献者。自从 Rust DevTools 团队成立 以来，我们也一直在与其他工具匠讨论如何促进对通用工具的贡献。期待很快听到更多关于这方面的信息。
最后，我们还推出了 bindgen 用户指南，帮助人们在他们的项目中使用 bindgen。
(感谢 Nick Fitzgerald 的撰写。)
其他语言/环境
高级语言带来了自己的集成挑战，通常涉及与外部运行时系统（可能包括垃圾收集器）的合作。以下是关于这方面的一些主要项目的简要概述
- Ruby: Helix 项目旨在用 Rust 编写 Ruby 扩展，并在几个月前公开发布。
- Node.js: Neon 项目类似地旨在用 Rust 编写 Node.js 模块，并且继续活跃开发。
- GNOME 对象系统: 在 Rust 和 GNOME 核心开发人员的联合冲刺之后，我们有了 Rust 和 GObject 系统 集成故事 的基础。
- Rust FFI Omnibus 为从各种语言调用 Rust 的基础知识提供了指导。
在这个领域还有许多不太引人注目的项目；如果您希望您的项目被跟踪为路线图的一部分，请在 跟踪问题 上发表评论！
结论
总之，您可以看到 Rust 世界在过去六个月里非常繁忙。我要感谢所有参与推动这些项目完成的人！