2023年Rust展望：这两件大事必须优先解决

以前，Rust 核心团队会征集博文来帮助制定下一年的计划。近几年，核心团队似乎消失了，当然也没有征集博文，但我还是要写一篇，因为我有一些意见想让他们听到。请原谅。我觉得你也应该写一篇这样的文章！

本文最初发布于Nick Cameron的个人博客。

首先，感谢 2022 年的 Rust！感谢所有贡献者、团队、基金会、社区和用户。这是忙碌的一年，如果没有这多人付出了如此多的努力，而且通常是作为志愿者，这一切就不会发生。所以，谢谢大家！

今年 9 月，我写了一篇关于 Rust 面临的十大挑战的文章，我认为那些是应该在 2023 年（也可能是 2024 年）努力解决的问题。也许，我可以就此打住，但关于 2023 年应该优先考虑什么，我还有一些看法。

首先，无疑也是最重要的，我们（Rust 项目）需要解决治理和领导问题。这妨碍了许多潜在的工作，而且持续的时间越长，项目积累的“治理债务”就越多，问题也就越多。令人尴尬的是，在核心团队内讧一年之后，关于新的领导团队，甚至连一个建议都没有。(我在此向那些致力于此的人发出呼吁，我知道，因为人的原因，这个问题很难解决）。

我认为，Rust 治理还有很多工作要做，主要是更新 RFC 流程，重新审视团队和工作组结构。但因为没有一个领导团队来完成当前的变革，那些工作都停滞了。

其次，我认为我们需要重新审视“稳定而不停滞”的策略，在某种程度上，这也是受缺少领导团队所妨碍。避免停滞非常重要，我们不能停止创新，但我们也不能无限制地发展这门语言。语言的复杂性和规模都是有代价的，那有悖于 Rust“让人们能够编写出可靠的高性能软件”这一使命（在我看来，这需要让语言更简单、更小、更容易使用）。仅仅保持向后兼容并不意味着实现了稳定性。我有点担心正在讨论或设计的新功能的数量，关于这门语言的发展方向，似乎没有一个行动计划（或者至少，没有一个已发布的行动计划）。

无论如何，我不认为我们应该停止创新或放慢脚步，但我确实认为，我们需要找到创新的方法，我们应该超越“试验 ->每晚 ->稳定”这样一个管道。我们需要一个框架，让创新可以发生在核心社区之外，而不能让所有工作都发生在用户非常依赖其稳定性和成熟度的这门语言上。

一个局部解决方案可能是开始计划 2.0 版本。请先听我说，我知道向后兼容对 Rust 的成功而言很重要，更改令人害怕。但是，正在讨论的更改将极大地改变这门语言的特性，每十年一次的破坏性更改也并没有多么糟糕，我觉得，在某种程度上，我们可以通过工具来减轻这种破坏。此外，有一个 2.0 分支，我们就可以试验激进的想法，或许可以从中学到一些东西，然后放弃那些想法，即使我们从来没有真正推出 2.0，那也会很有用。我认为，2.0 项目是保持创新、保持志愿者热情、同时保持 1.0 分支相对稳定的一个好方法。重要的是，2.0 版本将是一个删除功能的机会，而不是不断地添加新功能。也就是说，如果没有 2.0 版本，我们就会被困在语言的单调增长中（好吧，不同的版本情况会有所不同，但基本如此）。

同样，我认为是时候开始“重写”编译器了。是的，通常来说，重写不好，但重写的缺点是放慢了当前编译器的相关工作，我认为，鉴于 Rust 的成熟度，这并不是一件多糟糕的事。如果这个项目没有成功，我们仍然可以学到一些东西。另一方面，潜在的好处非常大！在当前的架构下，实现增量编译、并行编译等非常困难。重新开始让我们可以应用我们从始至今学到的所有东西，我们可以借机认真改进编译时间，大幅简化未来的开发。结合语言的 2.0 版本，我们可以减少由于向后兼容而导致的一堆技术债务，并改进语言，实现更快的编译。

Cargo：Cargo（crates.io）是一个非常重要的工具，处于很多重要事情的关键路径上（供应链安全、一般安全、与其他语言集成、与其他构建系统集成、构建时间......），但资源投入严重不足，几乎不可能取得什么进展（说白了，这里不能怪目前的团队，在当前恶劣的条件下，他们已经做得很好了，正是由于他们的努力，事情才没有完全爆发）。我认为，我们有机会解决这个问题：向 Cargo 和 crates.io 团队中任何愿意接受的人提供资金，大力指导潜在的团队新成员（如果不存在这样的人，就说服支持 Rust 的一些大公司，让他们每家找一个人把 1/4 的时间花在 Cargo 上），用这些人迅速扩大团队（即使他们只对代码库等有部分了解），再次开始鼓励贡献和新功能。希望有令人兴奋的事情发生，并且有充足的审查能力，那样就会形成一个良性的贡献循环，让我们走出目前的困境。

异步：异步编程的相关工作进展得很顺利，我希望 2023 年事情开始好转并取得实实在在的成果。关于这一点，我对自己的缓慢进展感到有些沮丧，遗憾的是，大多数异步 WG 都在忙着其他事情，不过事情正在发生变化，我认为，对于异步来说，2023 年将是令人兴奋的一年。它应该仍然是该项目的一个高度优先事项。

不安全编程：不安全代码指南工作组及其他一些人在定义 Rust 内存模型方面做了很多工作，并为不安全编程提供了工具和指南。我认为，对 Rust 来说，进一步推进这方面的工作非常重要。安全性是 Rust 的主要卖点，为了让不安全编程变得更安全、更简单，我们做的越多越好。

完工和打磨：我请求 Rust 团队更多地专注于完成一些事情并打磨不完善的地方，而不是开始新的事情。有那么多不稳定的、部分实现的功能，还有那么多早就计划好但缺失的功能。我认为，实现这个列表上的功能对 Rust 用户（和潜在用户）的影响比任何正在讨论的新功能都要大得多。

一个有点不确定的因素：我真的很想看看，Rust 数据分析 / 数值计算明年会是什么情况。这是一项完全由社区主导的工作，有一些真正令人兴奋的事情正在发生（特别是 Polars，非常酷）。我认为它非常适合 Rust，在成熟度方面，它似乎达到了一个拐点，我真想看看它是否会起飞以及飞向哪里。

祝大家 2023 年快乐！

在措辞上，我已经刻意谨慎了，但还是不够谨慎。关于“2.0 版本”的那一部分被很多人引用，但那只是这篇文章的一部分，只是我个人的一个想法。

显然，“2.0”意味着很多不同的东西。我认为，推出一个破坏性的大版本是一个非常糟糕的主意，我们不应该这样做。我是觉得，如果该语言一直这样单调地发展下去会出问题，我们需要找个地方进行实验，严格遵守向后兼容的原则会增加很多事情的难度。但稳定性非常重要，对稳定性的重视让我们所有人都受益匪浅。

我认为，对于向后兼容性，采取稍微灵活一点的态度对某些领域来说可能是有益的。我不知道那会是什么样子，也许会是一个版本更改，删除了弃用的功能；也许那意味着 crate 是跨版本二进制兼容的，但需要用不同的编译器编译（是的，我知道，二进制兼容，lol）；也许那意味着在运行新的编译器之前，你需要在代码上运行一个工具。对我来说，所有这些事情都属于“2.0 缓解措施”的范畴。关键是用户不会处于类似 Python 3 或 Perl 6 那样的情况。

从某种程度上讲，我觉得需要有一个地方来试验 Rust，而不是在每晚构建中。我在文章中把它和 2.0 的想法混为了一谈，这是我的失误。我在这里的想法是，对于大特性，应该有一个地方来试验其实现，而且这个地方还要是官方的，但这并不是说要加速添加到 Rust 稳定版或包含在分布式编译器中。

感谢每一个指出这一点 / 参与讨论的人！

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.ncameron.org/blog/rust-in-2023