当 Rust 成为“巨坑”：拖慢开发速度、员工被折磨数月信心全无，无奈还得硬着头皮继续
qf0ix2
9
作者|Matt Welsh 译者|核子可乐 策划|褚杏娟 坦白说，我（笔者）在写这篇文章之前犹豫了很久，我怕文章最终沦为各方编程语言势力口诛笔伐的导火索。但确实有很多朋友会问我 Rust 用起来怎么样、要不要在他们自己的项目里选择 Rust。思来想去，我最终还是决定分享一些初创公司环境下 Ru?st 的使用心得，聊聊这种语言跟快速行动、扩展团队这两大核心目标间的冲突。
我其实挺喜欢 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
福利推荐：
12月25-26日，ArchSummit全球架构师峰会将落地北京海航万豪酒店。来自百度、京东、华为、腾讯、斗鱼、中国信通院等企业与学术界的技术专家，将就数字化业务架构、低代码实践、国产化替代方案、分布式架构等主题展开分享讨论。
会期临近，门票即将售罄，购票或咨询其他问题请联系票务同学：15600537884（微信同电话）
今日荐文点击下方图片即可阅读
瞧不上 C++ 和 D 语言，国外程序员将 5.8 万行代码迁移到 Jai 语言，到底图什么？
你也「在看」吗？
相关文章
-
原文作者：JeffreyM.Perkel虽然学习曲线很陡，但是Rust兼具速度和安全性。2015年，生物信息学家JohannesK?ster还是（用他自己的话说）"差不多全职写Python的"。他当时已经用Python写过一个备受欢迎的工具--流程管理工具Snakemake。现在，他正在准备写的项目所要求的计算能力超过
鹿雅七
4 3
0 条评论
-
作者|蔡芳芳 前不久，Rust编程语言的审查团队（ModerationTeam）通过GitHub宣布集体辞职，在技术圈引发了一场关于开源治理的热烈讨论。Rust社区的关注度也随之飙升，相关报道在朋友圈持续刷屏。一位圈内人士对此调侃道："知道Rust火，没想到能这么火。"上一次Rust获得这么高的关注度，还是2021年初
mrbai2013
17 3
0 条评论
-
新智元报道来源：reddit 编辑：小匀 【新智元导读】继AWS、谷歌、华为、微软和Mozilla后，Facebook近日也宣布加入Rust基金会，并承诺将会加大对Rust的采用。这个编程语言最近非常受青睐，相比较C和C++而已更快速、更安全的它，对编写驱动程序和编译器等组件很有吸引力。 近日，Facebook宣布以
日耳曼蔷薇
6 4
0 条评论
-
喜欢就关注我们吧！Rust官方博客发布了2020年度的Rust调查报告。 此次调查共收到以14种不同语言完成的8323份回复，使用英语的受访者人数占比最高，为75%，其次是5.4%的中文受访者以及5.3%的俄语受访者。基于此，官方计划从这语言方面改进Rust社区，为那些不希望或无法使用英语的人改善Rust社区状况。 在
杭州娱乐子龙
8 1
0 条评论
-
作者|PaulBiggar 译者|弯月，责编|杨碧玉头图|CSDN下载自东方IC 出品|CSDN（ID：CSDNnews）以下为译文： 我们编写了一门语言，其中集合了编程语言、结构化编辑器以及基础设施等所有功能，我们的目标是将构建后端服务的难度降低100倍。我们的这门语言采用了F#，很多人都对此表示很惊讶，包括我在内
菇凉积
6 3
0 条评论
-
LinusTorvalds发表Rust支持即将出现在Linux内核，并提出首个初始提交应该`包含尽可能少的功能`的要求之后，Rust-for-Linux团队将已开发的部分驱动程序和驱动支持所需的代码裁剪之后，Linus于2022.10.16发布了Linux6.1-rc1开发版本，其中已正式包含Rust相关代码，实现Ru
带钉的心tlNN
7 1
0 条评论
-
现有的编程语言非常多，大家都习惯了要在性能、表达力和内存安全之间取舍，直到Rust横空出世。 对于Rust这个新语言，很多人可能都听过，但是没用过。实际上，早从16年起，Rust已经连续六年霸榜，被StackOverflow评选为最受开发者喜爱的语言。数百家科技公司在使用Rust，其中不乏一些世界顶级公司，比如苹果、亚
lf0ae8
6 3
0 条评论
-
作者|MikeTang 责编|Aholiab 出品|区块链大本营（blockchain_camp) 2015年5月15日，Rust编程语言核心团队正式宣布发布Rust1.0版本。 4年来，它优雅的解决高并发和高安全性系统问题的能力，受到了越来越多开发者的喜爱。并且连续4年，在StackOverflow开发者「最受喜爱
xd9304
5 6
0 条评论
-
作为一门系统编程语言，Rust一直致力于解决高并发和高安全性系统等问题。和老牌的C++相比，Rust的性能也毫不逊色。但曾几何时，因为上手难、用户量少、社区不活跃等诸如问题让想要入门的开发者感到迷茫，如今新的一年已经开始，我们是否真的有必要学习Rust？ 作者|NickHeath 译者|虎说 责编|屠敏 出品|CSD
skyeee
4 0
0 条评论
-
最近一段时间Rust似乎开始从默默无闻走向聚光灯下，从微软宣布探索采用Rust替代C/C++，到Linux内核维护者表示愿意接受Rust作为驱动开发语言，再到AWS公开表示赞助Rust，同时连续4年被票选为StackOverflow最受欢迎语言的光辉事迹又被搬出来。频频高亮曝光，让"Rust到底能不能成？"、"以后不用
谔地平线授本
3 1
0 条评论
