每年，我们都会要求社区撰写有关他们希望在Rust的明年路线图中看到的内容的博客文章。 这是我在2019年的Rust帖子。

Rust 2021: 成熟

今年也有点特别; 在2018年，我们对Rust推出了大约三年的版本时间表。 所以现在不仅是思考2019年的好时机，而且也是2020年和2021年的时候。 Rust在2015年的一些思考是关于“稳定性”的。 Rust在2018年的一些思考是关于“生产力”的。我希望Rust在2021年的一些思考能够是关于“成熟”的。

为了实现这一目标，这是我们在2019年所需要的。

No new features(新特性，但不是新事物)

Emphasis on “new” here. What do I mean by this? Well, there are a few features that are in the pipeline that I do think should land:

async/awaitGATsconst generics

And possibly(可能的特性)

Specialization

这些功能都不是新的; 我们已经有了他们的基本设计。 这些特征也具有重要意义和基础性; 我们需要 sync/await（或者GATs）来建立一个伟大的网络编程体系，我们需要const、泛型来获得一个优秀的数值系统。

但那之后呢？ 如果可以的话，我更愿意我们受限在2020年或某一年，在这之前暂停主要功能，

我们已经到了一个甜蜜期。 我们总是说Rust 1.0是稳定的而不是完整的。 我想我们正在快速接近完整。

也就是说，我不认为语言团队应该解散; 我认为他们的工作应该过渡到详细说明我们已有的东西。 我不确定我们是否可以在2019年完成 reference 的编写（稍后会详细介绍），但我希望它能够更进一步。 这只能在语言团队的帮助下进行，他们只有在有时间的情况下才能进行这项工作。

优化RFC（Request For Comments征求修正意见书）流程

RFC流程需要重新进行设计。 Niko在6月份写了，我认为这真的非常非常重要。 我想在RFC上提出这个建议，所以如果你有兴趣，我们应该谈谈。

Niko已经提出了案例，并提出了一些基础，所以我不会说更多。

减少团队债务

考虑到我对的文章所说的所有内容的认可。 我不能说得比它更好，所以我会把它留在这。

解决文档的可持续性问题

今年对于文档团队来说是糟糕的一年。 这本书出货了，这很棒。 我们有一些人参与 reference的编写，他们的工作是惊人的。 一些其他文档编写者继续研究rustdoc，这很重要。

但是，我们想要做编写更多文档的目标从未实现过。 例如，从未没有为主要的生态系统 crates 做出贡献、手册没有完成、 Rust by Example仍然萎靡不振。 标准库还不够友好。

我们只是没有让人们做到这一点。 我们已经尝试过，但没有任何效果。 这可能是根本无法修复的，毕竟大多数程序员都不喜欢编写文档。 但我也不想放弃它。 我不知道该怎么做，但我知道这是一个主要问题。

总而言之

还有很多工作要做，我很高兴能做到这份工作。 我认为Rust是一个很好的东西，通过一些工作，我们可以让Rust在一年的时间里变得更加令人振奋。