今年一月，我们通过了2017 Rust 路线图，其中列出了我们 2017 年的计划。作为路线图流程的一部分，我们计划定期发布各路线图项目的进展更新。本文标志着这一年的过半。
通过路线图 issue 跟踪进展
首先，一个元说明。如果您想跟踪某个特定路线图倡议的进展，或了解如何参与其中，最好的地方是rust-roadmap 仓库上的 issue 列表。在那里您会找到专门针对我们正在推进的每个主要倡议的 issue。这些 issue 包含指向正在进行的工作的链接。在接下来的描述中，您会找到一些类似这样的 issue 链接。
Rust 应该降低学习曲线
降低 Rust 学习难度最直接的方法是改进我们教授它的方式。为此，我们一直在努力编写全新的官方版“Rust”书籍（路线图 issue），现在我们已经有在线提供的完整草稿。这新版本将所有权置于核心位置，并且还扩展了对 Rust 中许多其他领域的覆盖，例如错误处理、测试、模式匹配、模块等等。更好的是，您可以通过 No Starch Press 预订印刷版本。如果您想帮忙，仍有大量编辑工作要做！
我们还在研究一些语言更改，旨在改善语言人体工程学。这些包括长期存在的提案，例如非词法生命周期或impl Trait，以及更新的想法，例如最近批准的关于trait 别名和match 人体工程学的 RFC。在路线图 issue 中，您会找到一个庞大的倡议列表，按它们针对的语言部分进行组织（例如，所有权/借用，trait 系统等）。我们正在积极寻找愿意帮助编写 RFC 以及实现已接受 RFC 的人——如果您有兴趣帮助处理某些事情，请查看路线图 issue 或特定 RFC 的跟踪 issue 中列出的“指导”联系人。当然，如果您认为您有一个未列出的好想法，请在 internals 上开启一个讨论帖，我们来谈谈！
Rust 应该提供流畅的编辑-编译-调试循环
我们一直在通过多种不同方式来解决编译器性能改进的问题。其中最简单的一种是我们在 Rust 1.16 中发布的 cargo check 命令——这个命令执行一种有限的编译形式，它跳过代码生成，只查找错误。由于代码生成通常占编译时间的 50% 或更多，这在编写新代码并尝试编译的早期阶段会非常有用，特别是如果您的项目包含多个 crate。RLS 也使用了这个命令。
当然，最终您需要运行代码，为此您需要完全编译。为了加快这个过程，我们一直在努力重构编译器，使其能够增量工作。今年早些时候，我们在 nightly 版本上发布了增量编译的“beta”版本。虽然 beta 版本有时能实现相当大的加速，但我们也发现依赖跟踪不如我们期望的那样健壮或有效。因此，我们现在正在采用一种新的、改进的增量编译方法，预计将在未来一个月左右准备就绪。如果您有兴趣帮助过渡到新系统，请查看增量编译路线图 issue 或新算法本身的跟踪 issue；您也可以关注这个 internals 讨论帖，我们会定期发布包含指导说明的 bug 链接。
除了增量编译，我们还在采取其他措施来优化编译时间。这方面可能最重要的步骤是perf.rust-lang.org 网站新版本的搭建和运行。“perf”网站跟踪每个 PR 对编译性能的影响，以便我们能够检测和纠正性能退化。事实上，新网站立即带来了一些重大的性能改进。然而，仍有大量工作可以做来改进它，从评估和改进我们的基准测试套件到改进 Web 界面；更多信息请参见关于此主题的跟踪 issue。
Rust 应该提供扎实但基础的 IDE 体验
自去年 RustConf 上首次亮相以来，Rust Language Service (RLS) 一直在快速发展（路线图 issue）。它现在支持大多数基本的 IDE 操作，例如“跳转到定义”或“查找所有用法”，并提供代码补全（通过racer 项目）。目前，重点主要放在完善：使 RLS 更容易安装和修复 bug。例如，我们最近实现了通过 rustup 直接安装 RLS。
如果您想尝试 RLS，最简单的方法是使用VSCode 插件；但是，RLS 是一个通用服务器（它遵循 Microsoft 的语言服务器协议），并且也有适用于许多其他编辑器的客户端可用。友情提示：目前，RLS 仍处于“alpha”阶段。虽然它非常可用，但您可能会遇到 bug 或其他限制。
如果您想参与 RLS，请查看路线图 issue 或RLS issue 列表；特别是那些标记为“good first issue”的。
Rust 应该提供易于访问的高质量 crate
随着 crates.io 生态系统的规模不断增长，crates.io 网站使用的简单搜索和排序标准不再有助于弄清楚您应该使用哪些 crate。为了解决这个问题，我们添加了类别和许多徽章，crate 作者可以将其添加到他们的 crate 中。这些有助于人们查找特定用途的 crate，并一眼判断 crate 的质量。此外，RFC 1824 制定了改进 crates.io 默认排序和公开额外信息以帮助选择 crate 的计划。有一个跟踪 issue 列出了此 RFC 的各个部分，我们非常欢迎为此做出贡献！一旦 RFC 完全实现并且人们有机会使用这些功能一段时间后，我们计划向社区征求反馈并进行调整。
此外，下文所述的关于“cookbook”的努力也将有助于以任务为中心的方式发现 crate。
Rust 应该非常适合编写健壮的服务器应用
今年上半年，我们在让 Rust 适合编写健壮的服务器应用方面取得了显著进展。futures crate 和 Tokio 项目继续探索异步 I/O 生态系统，并通过 Hyper 等 crate 和 linkerd-tcp 等生产用户看到了大量应用。此外，我们还看到像 Rocket 这样的项目继续不懈地改进 Rust 在服务器端的人体工程学。最近一次讨论关于当前最大的障碍是什么，突出显示了 async/await 语法、更好的 Tokio/future 文档，以及为生态系统提供坚实 HTTP 基础是接下来的一些最高优先级。我们计划在今年年底前在 nightly Rust 通道上启用 async/await 语法，并将其定位在 2018 年初稳定。这反过来应该有助于推动 Tokio/future 文档的重写，并继续增加社区对 HTTP 等 crate 的支持。
Rust 应该拥有用于基本任务的 1.0 级别 crate
Libz Blitz 进展迅速！Libz Blitz 是一项系统性的努力，旨在识别 Rust 生态系统中应用最广泛的 crate，并确保它们都达到一致的完整性和质量水平。这项工作包括在 internals 论坛上协作根据API 指南评审 crate，提交并解决出现的问题，以及为新的Rust 示例“cookbook”编写示例。
这项工作的结构非常适合贡献，特别是对 Rust 新开发者而言，到目前为止，通过 53 位贡献者的努力，已在 10 个 crate 中解决了 99 个 crate issue，并为 cookbook 创建了 30 多个示例。
如果您有兴趣参与，请查看internals 讨论帖上的介绍文章。
Rust 应该易于集成到大型构建系统
构建系统集成的大部分工作都集中在更清楚地识别挑战以及制定针对这些挑战的具体提案。目前正在探索的一些途径包括：
- 支持使用 Cargo 创建构建计划但不执行它
- 以一流的方式支持声明外部依赖项（而不是像今天这样通过任意构建脚本）
我们希望在今年下半年加快这项工作的步伐，但需要帮助。如果您对上述任何 Cargo 改进感兴趣，或者您对构建系统集成有一般性的见解，请在跟踪 issue 上联系我们！
Rust 社区应该在所有层面提供指导
在指导方面，我们一直在推行一些不同的倡议。首先是RustBridge，它专门旨在将缺乏代表性的人群带入技术领域；它也为完全不懂 Rust 的人提供了一套优秀的课程材料。这些材料已经经过了几次迭代，并持续演进和改进，我们将在RustConf 前一天举办 RustBridge 工作坊。我们希望看到更多 RustBridge 活动。
我们还刚刚启动了“提升 Rust 影响力”倡议，旨在更多地听取目前在 Rust（或更广泛的技术领域）中代表性不足的群体的意见，并共同努力使 Rust 更容易被更广泛的受众接受。虽然这本身不是一个指导项目（在许多情况下，是参与者在教学！），但它仍然旨在降低加入 Rust 社区的门槛。
此外，各个 Rust 团队一直在推行一系列不同的倡议，试图鼓励人们参与 Rust 项目本身：
- 我们新增了三个团队——infrastructure（基础设施）、cargo 和 dev-tools（开发工具）——从而创造了新的领域供人们参与。
- lang 团队采用了新的“shepherd”（牧羊人）角色。Shepherds 是经验丰富的社区成员，他们既表现出卓越的技术敏锐度，又有建立共识和理解不同观点的能力。Shepherds 参加语言会议，帮助引导对 RFC 的讨论，并将其引向有益的结论。
- lang 团队也一直在研究“指导性”RFC。例如，人体工程学倡议的路线图 issue 列出了我们正在积极招募参与者的许多 RFC。
- “Libz Blitz”的一个重要部分是帮助引导社区力量将库推向完成。
- 编译器团队一直在积极寻求“指导性 bug”（标记为 E-mentor 的 bug），这些 bug 包含书面说明，并制定计划改进代码和工作流程的文档。
探索领域
除了主要的路线图项目，路线图 RFC 还指出了两个“探索领域”。这些领域对 Rust 具有强大的潜力，但仍处于更具探索性的阶段。
嵌入式 Rust 倡议
嵌入式 Rust 生态系统持续增长。最近为 Cortex-M 微控制器开发了一个裸机并发框架，面向机器人和控制系统。而针对 Cortex-M 微控制器的嵌入式操作系统 Tock 正在向纯 Rust 用户空间应用迈进，并持续增加其驱动支持。
在编译器方面，由于社区的努力，对 MSP430 架构的支持一直在改进，并且社区还在树外努力支持 AVR 架构。
在社区方面，通过创建和开发指南、项目模板、核心 crate 和工具，标准化开发工作流程的努力正在进行中。最近进行了一项调查，以确定嵌入式开发人员当前的需求，并更新了相应的路线图 issue 以反映结果。为了响应调查结果，启动了一项社区工作来创建一个硬件抽象层（HAL），它将作为构建嵌入式 crate 生态系统的基础，目前正在进行设计讨论。一个反映嵌入式生态系统最新状态并跟踪其进展的“我们嵌入了吗？”网站也在开发中。
（感谢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 的基础指南。
这个领域还有许多不那么引人注目的项目；如果您的项目希望被纳入路线图跟踪，请在跟踪 issue 上留言！
结论
总之，正如您所见，在 Rust 领域过去的六个月里非常忙碌。我要感谢所有为推动这些项目完成而付出努力的众多人士！