一些关于Rust在2019年的思考

每年，我们都会要求社区撰写有关他们希望在Rust的明年路线图中看到的内容的博客文章。 A call for Rust 2019 Roadmap blog posts这是我在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:
这里强调“新”。这是什么意思？好吧，我认为应该落地一些关于 pipeline 的功能：

async/await
GATs
const generics

And possibly(可能的特性)

Specialization

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

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

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

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

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

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

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

减少团队债务

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

解决文档的可持续性问题

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

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

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

总而言之

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