当 Rust 成为“巨坑”：拖慢开发速度、员工被折磨数月信心全无，无奈还得硬着头皮继续

坦白说，我（笔者）在写这篇文章之前犹豫了很久，我怕文章最终沦为各方编程语言势力口诛笔伐的导火索。但确实有很多朋友会问我 Rust 用起来怎么样、要不要在他们自己的项目里选择 Rust。思来想去，我最终还是决定分享一些初创公司环境下 Rust 的使用心得，聊聊这种语言跟快速行动、扩展团队这两大核心目标间的冲突。

 

我其实挺喜欢 Rust，也绝无抹黑 Rust 的意思。但亲身经历告诉我，选择 Rust 几乎必然会对生产力造成重大影响，影响到快速行动这个基本目标。所以动手之前，请大家认真权衡 Rust 造成的速度影响到底能不能抵得上它给业务和产品带来的收益。

Rust 是那种优缺点都很明显的语言。如果大家的项目需要 Rust 的某种特性，如高性能、超强类型、无垃圾收集的系统语言等，那它确实表现很棒。但 Rust 也有相当不擅长的场景，即团队为 Rust 的复杂性和编写开销付出了代价，却得不到什么好处。

我对 Rust 的主要体验来自之前在一家初创公司的从业经历，前后大概持续了两年多。那是一个基于云的 SaaS 项目，也算是一个基于传统 CRUD 的应用程序：包含一组微服务，在数据库前提供 REST 和 gRPC API 端点，外加一些后端微服务（本身是用 Rust 和 Python 混合实现的）。

之所以使用 Rust，是因为公司的几位创始人都是 Rust 专家。但随着时间推移，我们的团队规模显著扩大（工程人员数量增长了近 10 倍），代码库的规模和复杂度也随之快速提升。

随着团队和代码库的并行膨胀，我意识到公司为了继续使用 Rust 而付出了更高的代价。有时候开发速度非常缓慢，新功能的发布时间也比我预期得更长，人们都感觉到当初选择 Rust 的决定并不利于释放生产力。

从长远来看，换一种语言重写代码反而能让开发更灵活、加快交付时间，但问题是我们难以抽出完整的时间来推进这项重写工作。总之，我们有点被 Rust 困住了的感觉，任何解决办法都没那么容易实现，我们需要硬着头皮强上。

这些情况好像跟很多朋友的固有印象不同。那么，既然 Rust 语言如此安全稳定、性能卓越，怎么在我们这就不灵了呢？

陡峭的学习曲线

在整个职业生涯里，我接触过几十种语言，而且大部分都是现代的过程化语言（例如 C++、Go、Python 和 Java 等），它们的基本概念都高度相似。虽然每种语言之间也有差异，但主要体现为跨语言的模式区别，掌握起来并不太困难。

但对于 Rust 来说，我发现最困难的其实是接纳一整套全新的思路——比如生命周期、所有权和借用检查器等。即使是经验丰富的编程老鸟对这些定义也并不熟悉，因此必然会面对一段颇为陡峭的学习曲线。

当然，其中一些“新”思路在其他语言中也有体现，特别是在函数式语言当中。但 Rust 是第一次将其全面引入“主流”语言环境，自然令众多 Rust 新手苦不堪言。虽然我的同事们都非常聪明、也很有开发经验，但包括我自己在内的很多人都难以理解 Rust 中的某些实现规范、看不懂编译器中为何经常出现神秘的错误消息，也不明白关键库的工作原理。

为此，我们开始每周为团队举办“Rust 学习会”，分享知识和专业意见。但开发速度放缓已成事实，这极大削减了团队的生产力和士气。

作为鲜明的对照，我当初在谷歌工作时曾从 C++ 全面转向 Go 语言，整个过程只用了不到两周时间，十五人的团队在首次编写 Go 程序时感觉相当轻松。但在 Rust 上，即使是在全职开发了几个月后，团队中的大多数成员还是觉得很没有信心。不少开发者告诉我，他们心里感觉很难受，因为功能实现所需要的时间比他们预期要长，而这一切都源自他们被迫以 Rust 的方式去思考。

Rust 并不特别，总有语言可以替代它

如上所述，我们构建的服务是一个比较简单的 CRUD 应用。在这套系统的整个生命周期中，服务的预期负载不会超过每秒几条查询，但该服务背后是一条相当复杂的数据处理管道，可能需要几个小时才能运行起来，所以该服务应该不会成为性能瓶颈。换句话说，就算是 Python 这类并不以性能见长的语言，在这样的场景下也绝对不会惹出什么麻烦。

另外，除了面向 Web 的服务需求处理之外，该服务也没有任何特别的安全或并发需求。我们之所以使用 Rust，唯一的理由就是这套系统的发起者是 Rust 专家，跟语言本身的特性和适应性毫无关系。

Rust 语言有个著名的设计权衡——安全性比开发生产力更重要。在很多场景下，这样的决断并没有问题：无论是在操作系统内核里构建代码，还是限制嵌入式系统的内存，这都很有必要。但除此之外，还有一些没必要那么在意安全的需求，特别是对于我们这样以速度决成败的初创公司。

我是典型的实用主义者，宁愿让团队花时间调试 Python 或 Go 代码中偶尔出现的内存泄漏或类型错误，也不愿让每个人都为了彻底回避这些问题而被迫将生产效率降低四分之三。

前文已经提到，我曾在谷歌团队用 Go 语言构建过一项服务。随着时间推移，该服务已经支持超过 8 亿用户，而且峰值期流量是谷歌搜索 QPS 的 4 倍。在构建和运行该服务的那些年里，由 Go 类型系统或垃圾收集器引起问题的次数其实一只手就数得过来。

基本上，Rust 所解决的问题用其他办法也能搞定——比如更好的测试、更好的 linting、更好的代码审查和监控等。除非实在拿不出这些资源，Rust 才可能是个不错的选择。

很难招聘到 Rust 开发人员

在这家公司供职期间，我们雇用了不少员工。但在 60 多人的工程团队里，只有两三位此前有过 Rust 开发经验。不是我们不愿意找有经验的 Rust 程序员，而是实在找不到。

所以大家在做决定之前一定要慎重，纯 Rust 开发其实真的不太符合创业环境的基本需求。没错，随着 Rust 变得愈发主流，相应开发人才肯定会越来越多，但至少就目前来看，这事并不容易。

还有另一个次要因素就是，团队中懂 Rust 的成员和不懂 Rust 的成员之间出现了割裂。由于这是一种较为“深奥”的编程语言，所以公司里原本能帮助构建功能、调试生产问题的其他工程师完全插不上手。这时候如果希望快速行动、发挥团队中每位成员的综合优势，Rust 就成了横亘在面前的最大障碍。

根据我的经验，程序员在 C++ 和 Python 之类的语言间其实可以轻松切换，但 Rust 太新、也太复杂了，拉高了人们之间的协作门槛。

库和说明文档都不成熟

我希望这个问题能逐步得到解决。但必须承认，跟 Go 语言相比，Rust 的库和文档生态系统都非常不成熟。

Go 的优势在于，其对外发布的一切成果都由谷歌的专项团队开发和支持，所以配套的文档和库也相当完善。相比之下，Rust 总有种“半成品”的感觉，库和说明文档严重缺失，人们往往需要查看库的源代码才能理解如何使用。这不好，非常不好。

Rust 的拥护者们倒也承认“async/await 还不成熟”以及“库说明文档确实不完备”，但光承认没用，这些问题实实在在影响了团队的开发效率。

我们早期采用 Actix 作为服务的 Web 框架时就犯了大错，后面引发了不少麻烦。这个库里深藏着各种 Bug 和问题，直到现在也不清应该如何修复。（当然，这是几年前的事了，也许现在情况已经有所改善。）

当然，这些问题也不是 Rust 特有的，但却成了开发团队无法回避的“技术税”。无论核心文档和教程有多么出色，如果不知道该怎么用那些库，一切都将毫无意义。

很难用 Rust 粗略地构建一项新功能

我不知道其他人怎么看，但就我个人而言，我在构建新功能前肯定不会做好数据类型、API 和其他所有细节准备。我一般是先把代码写下来，试试基本思路行不行得通。

在 Python 中执行这类操作非常容易，我们可以快速尝试、随意探索，不用担心粗略的构思会影响到某些代码路径。在确定行得通后，我们可以再回头整理内容、修复类型错误、编写测试，完全不耽误。

但在 Rust 中，这种“粗糙编码”的方式就非常困难，因为编译器可能会觉得每个不符合类型和生命周期检查的问题都是错误。这就是 Rust 的特点——设计必须明确。

如果我们需要构建的是生产就绪型产品，那这很对、很好。但如果只是想做点测试或者初步探索，那这样的特性就太糟糕了。虽然也能帮上点忙，但还是需要在编译之前对堆栈上下的所有内容进行类型检查。

更麻烦的是，当需要更改承载接口的类型签名时，我们会发现自己要耗费几个小时来变更各个使用到该类型的位置后，才能弄清最初的尝试可不可行。如果需要再做调整，那整个过程还得重新来一次。

结束语

Rust 肯定有一些我喜欢的东西，我也希望它的一些特性能被其他语言所吸纳。首先就是匹配语法，另外还有强大的 Option、Result 和 Error 特性，“?”运算符能够优雅地处理错误。这些设计在其他语言中也有类似的体现，但 Rust 从上到下都透着一股子优雅。

对于那些需要高性能、高安全性的项目，我绝对愿意使用 Rust。毕竟在这类项目里，我应该不会频繁修改项目的主体部分，对于速度也没有太高的要求。但在小型团队里，就不太适合全面使用 Rust 了——用来开发内核模块、固件、游戏引擎等是好的，毕竟它们都强调性能和安全性，而且在发布前往往难以进行彻底测试。但除此之外，请千万慎用 Rust，这语言可不好惹！

原文链接：

https://scribe.rip/using-rust-at-a-startup-a-cautionary-tale-42ab823d9454