我之前写过Rust 的未来，看来没人能阻止我再写一次！恰恰相反：这一次，Rust 核心团队甚至邀请我来写。我参加得有点晚了，但下面是我对 Rust 在 2018 年应优先考虑事项的一点看法。

这家伙是谁？

我们此前从未见过面的可能性高得令人沮丧——这实在太遗憾了。先介绍一下背景：我来自 Python 和 PHP 这类动态类型（dynamically typed）语言。Rust 是第一门让我能够编写真正的底层代码、却不觉得自己在和门卫争论的语言。

对我来说，Rust 不是一朵fireflower，而是我自己的Megazord¹。我希望 Rust 能够胜出，但为此，我们还需要从清单上勾掉几项。

提供编译器文档，让贡献变得更容易

我在俄亥俄州哥伦布参加Rust Belt Rust时，认识了Niko Matsakis（尼科·松崎）、Ariel Ben-Yehuda（阿里尔·本-耶胡达）和Santiago Pastorino（圣地亚哥·帕斯托里诺）。这些优秀的伙计在 impl-period(实现阶段)期间热切地投入到非词法生命周期（non-lexical lifetimes）的工作中。看着他们在编译器上不断敲代码，对我来说深受鼓舞，我开始琢磨自己是不是也能做点贡献。不用说，参与编译器开发的门槛可能相当高。我还没有做出任何贡献。

我很想做的一件事，是利用零碎的 30 到 60 分钟时间，时不时修复编译器中的一些小问题。事情可以简单到重命名一个变量、编写一个测试，或者补充一些文档。因此，我的第一个愿望是，让为这门语言做贡献变得更容易。可以通过提供充分的指导、更多适合入门者的工单，以及更好的编译器文档来实现这一点。这些建议Niko 已经提出过了。

为中级程序员提供更多资源

与此相关的是，我希望能看到更多面向 Rust 中级程序员的演讲、指南和书籍。这包括讨论如何在 Rust 中组织大型项目，以及 Rust 特有的设计模式（design patterns）。我想读到更多关于专业使用 Rust 的内容，也想看到来自各个行业的案例研究（case-studies）。例如，有一家名为 snips.ai 的初创公司，使用 Rust 构建了设备端语音助手。他们与 C 和 C++ 库进行了集成，我想更多地了解他们一路走来的经历。

改进 RFC 流程

我会尽量密切关注 RFC 流程，但我的时间有限。我希望打开任何一个 RFC 后，都能立即看到它的状态：

• 讨论的总结，以及主要的优点和缺点。
• 一开始就给出一个简单的使用示例。
• 朝稳定化（stabilization）迈进的后续步骤。

比如，如果我查看这个（并不那么）随机的 issue，我甚至不知道该从哪里开始。现在最大的阻碍是什么？谁在积极推动这件事？我能如何提供帮助？

Github 很适合放代码，但关于新特性的讨论经常会失控。这也不是 Rust 独有的问题。看看 Docker、Kubernetes 或 Node 等其他大型项目就知道了。也许我们需要一个新的工具来处理这类问题。

老生常谈的那些事

如果 2018 年可以要求两项特性稳定下来，我会选? in main和非词法生命周期。

当然，我还可以提到更多内容，但就不拿更快的编译速度、impl trait、生成器（generators）之类的话题来烦你了。我们在这些方面进展不错，去看看Nick Cameron（尼克·卡梅隆）的文章吧。

我相信，通过改进文档和指导机制，我们可以显著增加贡献者的数量，并在今年让许多备受期待的特性稳定下来。

^{1. 免责声明：我一集《Power Rangers》都没看过。↩}