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