我之前写过关于Rust 的未来的文章，看来没人拦着我再写一篇！恰恰相反：这次 Rust 核心团队甚至发出了征集。我来得有点晚，不过下面就是我对 Rust 在 2018 年重点方向的一点浅见。

这家伙到底是谁？

我们之前很可能素未谋面——这实在有点遗憾。先介绍一下背景：我来自 Python 和 PHP 这类动态类型语言。Rust 是第一门让我能够编写真正底层代码，却又不会感觉像是在跟门卫吵架的语言。

对我而言，Rust 不是一朵fireflower，而是我个人的Megazord¹。我希望 Rust 能赢，为此我们还有几件事需要完成。

完善编译器文档，让贡献更轻松

在俄亥俄州哥伦布参加Rust Belt Rust大会时，我见到了Niko Matsakis、Ariel Ben-Yehuda和Santiago Pastorino。这几位在 impl 期间全身心投入到了非词法生命周期的开发中。看着他们埋头打磨编译器的样子深深激励了我，也让我开始思考自己是否也能贡献一份力量。不用说，参与编译器开发的门槛还是相当高的。我至今还没能做出什么贡献。

我特别希望能利用零散的 30 到 60 分钟，随手修一修编译器里的小问题。也许只是重命名一个变量、写个测试或者补充一段文档。因此我的第一个愿望是，让参与这门语言的贡献变得更简单。这可以通过提供更系统的指导、更多入门级任务以及更完善的编译器文档来实现。这些其实都已经是Niko 提过的建议。

面向进阶开发者的更多资源

与此相关，我希望看到更多面向 Rust 中级开发者的演讲、指南和书籍。这包括如何用 Rust 组织大型项目的讨论，以及 Rust 特有的设计模式。我想读到更多关于 Rust 在专业场景下的应用，看到来自不同行业的案例研究。例如，有一家名为 snips.ai 的创业公司，用 Rust 构建了端侧语音助手。他们集成了 C 和 C++ 库，我想更多地了解他们的历程。

改进 RFC 流程

我一直在尽力紧跟 RFC 流程，但时间毕竟有限。我的愿望是，打开任意一个 RFC 都能立刻了解它的当前状态：

• 对讨论的总结，列出主要的优点和缺点。
• 一个简单的使用示例，就放在开头。
• 通往稳定化的下一步计划。

例如，如果我点开这个（并非）随机挑出的议题，我甚至不知道该从何看起。当前最大的阻碍是什么？谁在积极推进？我要怎么帮忙？

GitHub 很适合托管代码，但围绕新功能的讨论常常会失控。这也不只是 Rust 才有的问题，看看 Docker、Kubernetes 或 Node 等其他大型项目就知道了。也许我们需要为此寻找新的工具。

老生常谈

如果能在 2018 年许愿两个稳定特性，我会选? 在 main 函数中的支持和非词法生命周期。

当然还有很多可以说的，但我就不拿更快的编译速度、impl trait、generators之类的话题来烦你了。我们在这方面已经进展顺利，具体可以看看Nick Cameron 的文章。

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

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