微软首席工程师Nick Cameron：Rust要想取得更大的成功，需要解决这十大挑战

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

Rust 正处于非常有利的位置，它正变得越来越流行，贡献者也越来越多，而且被用在了一些相当重要的地方。然而，这是一个不断变化的时代，从一个研究项目变为一门快速变化的新语言，再成为一个发展势头良好的流行项目，这个过程是非常困难的。

在本文中，我想从个人角度介绍下 Rust 目前及今后几年面临的 10 个最大的挑战。对于解决之道，我有一些想法，但那都是些又大又难的问题，想找出答案并不容易。所以，真正的解决方案需要迭代，并为此付出精力、发挥创造力。

在开源工作中，对于项目来说什么是最好的，和贡献者想要做什么之间往往关系紧张。如果你足够幸运的话，两者能够保持一致，那自然没什么问题，但通常情况并非如此。有许多方法可以缓解这种紧张关系：给大家发放酬劳，有令人信服的愿景和良好的说服技巧，制定严格的 PR 接受策略，将事情游戏化，用宣传、感谢、授权或最终的工作机会等作为奖励来激励某些工作的参与者，等等。

随着 Rust 社区不断发展，以及 Mozilla 直接支持的结束，对 Rust 来说，这种关系似乎变得更为紧张了。虽然有很多人在做必要的维护工作，但往往还是人手不足，有一些重要的领域缺乏资源，也缺少一些战略性工作，贡献导向力显得不足。

在某种程度上，采用一种自上而下的方法可能更简单。不过，那将使 Rust 丧失作为开源项目的优势。这里有一个很大的挑战是，要确保那些重要但没有吸引力的工作有人做，同时又不会失去那些让它成为优秀项目的特质。

我认为，我们当前应该着力完成以下几项具体的事情：

• 先把一些已经开始的工作做完，而不是开始新的工作；

• 按照工具、库、非技术性工作、语言与编译器这样的优先级顺序开展工作；

• 优先考虑影响范围较小、成本较低、但完成后总体影响较大的工作（而不是大而迷人的工作）。与此相关的是，在开发过程中保持 Rust 项目的本色。特别是，项目如何发展并接受新的贡献者和领导者（以及由此而引发的不可避免的变化），而又不会忽视 Rust 的中心任务？随着观察员（和评论员）数量的增加，我们如何在讨论和决策过程中保持开放和透明？

尽管 Rust 以其热情友好的社区而闻名，但它的多样性数据却很糟糕，甚至比整个科技行业还糟糕。虽然在包容性方面，我们还算是一个做得比较好的项目，但事实是，还是有很多贡献者因为负面原因离开了项目，这表明我们应该做得更好（是的，避免倦怠也是包容性的一部分）。

包容性的一个重要方面是能够协调各种观点。如果我们只有在大家意见一致时才能和平共处，那么我们就不是多元化或包容性的。虽然在某些领域，对协商一致的偏好给我们带来了一些好处，但那也造成了一些问题。我们的文化更倾向于避免冲突而不是解决冲突，那是不健康的，会导致治理功能的失调。

要解决这些问题真的很难！但是，我们必须优先解决它们，即使很难，即使有时伴有阵痛。

过去这些年，Rust 取得了难以置信的发展，但我们的流程和组织结构却未能跟上发展的步伐。任何与治理或流程相关的变革都很保守。即使现有流程存在着巨大的损耗，除了微调之外似乎也不可能做其他任何事情。我们积累的组织债务已经如此之多，需要进行根本性的变革，但这会非常困难。

我认为，问题的核心是项目不愿意把“管理（management）”（人员管理、项目管理、产品管理）作为项目领导层的一个重要组成部分。这些事情可以独立于技术领导层，但需要真正的权力下放（而不仅仅是工作下放）。

项目面临的挑战是愿意授权，支持这些活动，并引入新的流程，为项目提供更好的支持。

Rust 在最小标准库和“batteries included”之间取得了很好的平衡，这得益于蓬勃发展的生态系统和简单易用的包管理器。然而，浏览 crate 生态系统一直很费劲。crate 有很多，要找出一个适合的需要做大量的工作，或是非常积极地参与社区活动。随着不积极参与社区活动的用户越来越多，以及 crate 数量的增长，这个问题会越来越严重。

异步编程对于 Rust 的许多应用领域来说都很重要，而且与 Rust 的编程模型非常契合。然而，这个生态系统在不同的运行时之间存在着一定程度的分裂，我们在这方面的改进工作一直很缓慢。我们在努力，但进展缓慢，最终能否成功也还是个变数。风险在于，我们最终把这些东西引入了标准库，而社区又不是很接受，最终导致这个生态系统比开始时还糟糕。

Rust 在其细分市场已经非常成功，而且我认为还有很大的发展空间。不过，Rust 可能远不止于此。如今，有很多软件都是用具有托管运行时的语言编写的，这些运行时对性能都非常敏感，而 Rust 注重安全性、人体工程学和性能，可以开发出更好的产品，提高生产率。然而，与 GC 语言相比，Rust 目前的学习难度还很大，需要付出很高的认知成本。让 Rust 更易于学习和使用可能会提升 Rust 的影响力。

我认为，支持 GC、提供针对Rc<RefCell<T>>类型的语法糖或是添加各种语法糖并不是这个问题的解决之道。我们要简化一些东西，但又不能使 Rust 丧失其作为系统编程语言的优势。减少显式生命周期的使用，增强借用检查器，避免 trait 系统过于复杂，关注用户体验，避免成为一门庞大的语言，这些都会有所帮助。也许我们会发现新的抽象，显著简化所有权和生命周期？

安全性是 Rust 的主要特性之一，也是许多人使用它的原因。遗憾的是，在安全的边界上是不安全代码，从安全到不安全没有一个平稳的过渡，只是一个不安全的悬崖，冰冷、可怕。我们需要提供更多的支持和更好的体验，让程序员完成不安全的工作。为此，我们需要更清晰地理解 Rust 的内存模型，然后再开发语言特性、库和工具。

所幸，这个领域很活跃，有学术研究、社区的出色工作、MIRI、不安全代码指南，等等。遗憾的是，这是一个非常复杂和困难的领域，许多来自外围的声音减缓了进展速度，增加了参与者的工作难度。一些真正有影响力的变更可能因为政治和技术原因而变得太大（参见上文的流程僵化挑战和下文的编译器的重大修改挑战）。

Rust 有一种严格而强大的方法来保持稳定性，包括针对向后兼容性定义了明确的保障措施。对于语言，一个版本可以有一些向后不兼容的演进而不会造成什么破坏。对于生态系统中的库，Cargo 和 Semver 文化亦使得演进成为可能。然而，对于标准库，除了单调发展之外没有其他任何方法（有些东西可以弃用，但永远不能删除，还有一些东西不允许修改）。

就其本身而言，这将导致标准库越来越大，越来越混乱。除此之外，还有一个次级效应：我们在稳定性方面必须非常保守，除了“永远稳定”和“只在 Nightly 版本可用并且完全可以更改”之外，API 再没有其他可能的状态（相比之下，对于 crate，pre-1.0 版本可能可以与稳定版的编译器一起使用，而 post-1.0 版本也可能要有选择地使用）。

与此相关，标准库是一笔全有或全无的买卖（技术上也有 liballoc）。有一个更细粒度的版本管理方案，让我们可以更细粒度地使用标准库，而不是要么核心库，要么全部，那将是非常有好处的。

Rustc 现在是一个相当庞大的软件，有很多内在的复杂性（Rust 是一种复杂的语言，在保证快速编译的同时给出良好的错误消息非常困难），有很多大型软件常见的问题，还有很多技术债务。这里有一些很大的挑战，特别是在编译时（其中，增量编译和并行编译是两种正在研发中的方法），并且都是些很难实现的工作。

像 Chalk 和 Pelonius 这样的工作是特别大的项目（要好几个人做好几年才能完成）。将来，做出重大修改只会越来越难。幸运的是，编译器团队有能力、有精力，而且资源丰富。但是，对 Rustc 进行影响重大的修改仍然很有挑战性。

宏有许多不完善的地方，也是该语言最不完善的部分之一。声明式宏引入了一种全新的子语言。过程宏很笨重，需要大量的依赖，并且很难掌握。所有宏在编译器（编译时间、增量编译、错误消息）和工具（IDE、rustdoc 等的各种问题）中的表现都很差。

我认为，这之所以成为一项巨大的挑战（不仅仅是又一个可以有针对性进行研究的语言特性）是因为这些问题涉及面广而且难度大。（可能）没有什么银弹，而只有大量的工程和设计工作。许多问题（如宏卫生性）需要的专业知识在社区中并不存在。宏的优先级不够高（毕竟，从根本上讲，它们还是有效的），对于贡献者来说也不够有吸引力。

像这样列出 10 个问题，并把它们都说成是“大”问题，可能会让人感觉有点消极。但我认为，这些都是现实存在的挑战。好消息是（我觉得是），所有这些问题对于从事项目研发的各类人员来说都是已知的，而且，对于其中的许多问题，人们正在积极地寻求解决之道。尽管任何解决方案的难度都不会小，但我认为，所有这些挑战都有切实可行的解决方案。

如果我们能够专注于解决这些问题（当然还有其他一些日常的挑战），那么我认为，Rust 将可以继续发展并取得更大的成功。

原文链接：

https://www.ncameron.org/blog/ten-challenges-for-rust/

今日荐文

点击下方图片即可阅读

周星驰招聘Web3人才：要有头脑又宅心仁厚；微软回应“泄露2.4TB数据”；罗永浩AR创业公司获近4亿元融资 | AI一周资讯

---

你也「在看」吗？ 👇