放弃Rust!Curl和Prisma弃用Rust后端,开发者反思18个月Rust重写经历:从狂热到后悔

Curl和Prisma弃用Rust后端,开发者反思18个月Rust重写经历:从狂热到后悔,引发对Rust实用性的讨论。

原文标题:接连被开源项目curl、Prisma弃用,Rust语言遭遇水逆,网友:从狂热粉到后悔莫及

原文作者:机器之心

冷月清谈:

知名开源项目Curl和数据库工具Prisma近日接连宣布弃用Rust语言,引发社区热议。Curl创始人Daniel Stenberg解释了放弃Rust Hyper HTTP后端的原因,主要在于缺乏用户需求和精通C和Rust的开发者,导致维护成本过高。Prisma则是因为Rust核心逻辑限制了TypeScript社区的贡献。与此同时,一位开发者Austin Starks分享了他用Rust重写算法交易平台的18个月经历,最终因Rust复杂的语法、语义和不友好的社区氛围而感到后悔。他认为Rust的错误信息不够直观,调试困难,且社区对批评意见容忍度低。这些事件引发了对Rust语言学习成本和实用性的讨论。

怜星夜思:

1、如果一个项目既要追求性能又要考虑安全性,Rust真的是最佳选择吗?有没有其他语言可以兼顾这两方面?
2、文章中提到的开发者在Rust社区遇到的不友好经历,是否是个例?Rust社区的整体氛围如何?
3、抛开技术层面,从项目的长期发展来看,选择Rust作为主要开发语言有哪些潜在的风险和挑战?

原文内容

机器之心报道
编辑:杜伟、大盘鸡

一时之间,Rust 编程语言陷入到了接连被弃用的窘境。

作为一门系统编程语言,Rust 专注于安全,尤其是并发安全。它支持函数式和命令式以及泛型等编程范式的多范式语言,在语法上和 C、C++ 类似。

图源:https://x.com/ThePrimeagen/status/1875592777440084416

就在刚刚过去的 12 月底,知名开源项目 curl 的创始人 Daniel Stenberg 宣布:将放弃支持基于 Rust 编写的 Hyper HTTP 后端,并彻底移除相关代码。此举引起了开发者社区的广泛关注。
旅程即将结束,实验结束了。我们努力过,但还是失败了。



2020 年,Stenberg 开始在 curl 中添加对另一种 HTTP 后端的支持,它使用了基于 Rust 编写的库,被称为 hyper。他的想法是引入一种替代的 HTTP 内部实现,从而可以让 curl/libcurl 使用它来代替本机实现。目标是借助 Rust 的内存安全性,为 curl 用户提供一个更安全的 HTTP 后端实现。

最初的工作得到了 ISRG 的慷慨赞助,它是「Let’s Encrypt」等出色工作的背后组织。期间 Stenberg 与 hyper 首席开发人员 Sean McArthur 密切合作,并取得了很大进展。到目前为止,Stenberg 已经在 curl 中以 EXPERIMENTAL 为标签提供了 hyper 支持,希望吸引用户的兴趣并激发他们的实验精神。

Stenberg 表示,他们已经完成了 95% 的工作,而且几乎整个测试套件都以相同的方式运行,无论构建 curl 时使用哪个后端。然而,正是那最后的百分之几却变成了最大的阻力,最终导致了项目失败、放弃并全部撤出。

为什么呢?总结起来,主要有以下两方面原因。

一方面,几乎没人有这样的需求,curl 的用户对 hyper 没有兴趣;现有的 hyper 用户也不关心它是否兼容 curl。

另一方面,libcurl 库是用 C 编写的,hyper 是用 rust 编写的,两者之间需要一个 C 粘合层。这就需要同时精通 C 和 Rust 语言的开发者来深入研究相关的架构和协议,来推动项目进展。现实却是缺乏这样的开发者。

因此,由于预计无法在短中期内完成 hpyer 工作,并且保留代码的成本实在太高,只能通过削减这些代码来提供灵活性并降低复杂性。

虽然 hyper 的实验本身失败了,Stenberg 认为他们从中吸取了一些教训,并在过程中改进了 curl。其实在 2020 年开始 hyper 项目的时候,Rust 语言本身并没有准备好。随着时间的推移,Rust 现在已经有所改进,成为一种更好的语言,并可以为类似 hyper 的项目提供更好的服务。

另外,在抛弃 hyper 之后,curl 仍然有两个 Rust 编写的实验性后端支持,分别是 rustls(用于 TLS)和 uiche(用于 QUIC 和 HTTP/3)。这两个后端在 crul 中使用了更好的内部 API,并以更干净的方式挂接到 libcurl 中,因而相较于 hyper 更易于支持,负担也更小。

目前,hyper 的超级后端代码已从 git 中删除,并且 2025 年 2 月发布的 curl 8.12.0 版本中将不会留下任何痕迹。

不过,虽然 hpyer 被移除了,Stenberg 对未来引入 Rust 或其他语言编写的安全后端持开放态度。未来会采用一些不一样的做法,毕竟与 2020 年开始 hyper 时相比,他们现在拥有了更好的内部架构。

无独有偶,在 12 月初,另一个开源数据库工具链项目 Prisma 也表态将从 Rust 迁移至 TypeScript,以追求更好的插件和扩展生态。

声明中写道:Prisma 的架构历来限制社区贡献,其核心功能(例如查询解析、验证和执行)由 Rust 引擎管理,而这对于专注于 TypeScript 的社区来说是不透明的。因此决定将 Prisma 的核心逻辑从 Rust 迁移到 TypeScript,并重新设计 ORM,以使定制和扩展更容易。


近几年 Rust 语言正在强势崛起,在一些编程语言排行榜中的排名一直在攀升,比如 2024 IEEE Top 编程语言榜单中,Rust 的排名就很靠前。另外,用 Rust 取代 C 和 C++ 的呼声也很高。


虽然 Rust 很强大且在安全性方面独树一帜,但它的学习成本也相对比较高。在一个关于「哪些原因阻止你在 2025 年学习 Rust」的调查中,有人抛出了一个有力的观点:他最常用的 C/C++ 库是同类中最好的,背后有数十年的开发经验。对于 Rust,他要么费尽心力地继续使用它,要么使用一些随机、不知名、没有血统的包。也有人认为,Rust 语法看起来很丑陋。

图源:https://x.com/kai_fall/status/1875549570513658212

用了 18 个月,我满满的都是后悔

其实,在 2024 年初,Medium 一篇文章讲述了作者花费了 18 月用 Rust 语言重建自己的算法交易平台的过程。虽然费了很多心思,但最终十分后悔。一起看看在这过程中,Austin Starks 到底经历了什么吧。


在文章开头 Austin 就表示了他曾经十分看好 Rust,甚至是 Rust 的狂热爱好者。Rust 看起来似乎是目前最快的、最安全编程语言之一。当然他发现不止自己一人这么认为。如果在网上阅读有关 Rust 编程语言的文章,你很可能会遇到压倒性的正面评价。每一篇 Medium 上的指南、每一篇 Reddit 上的帖子、每一个 Stack Overflow 上的回答 —— 一切都在赞美它。

这是故事的开始,或者说是「噩梦」的开始,Austin 决定放弃 TypeScript,将自己的整个开源算法交易系统重写成 Rust。

其实,这次不好的体验早有端倪。更早前,Austin 就写过一篇关于使用 Rust 的经历。他当时表示虽然非常喜欢 Rust 的速度和一些语言设计,但并不完全真正喜欢这门语言。不过文章一经发出,就遭到了猛烈的抨击。甚至有一条高赞评论指责 Austin 是用 ChatGPT 写的文章。这显然已经是 AI 时代人们对文字创作最大的批评了。


Austin 进行了反思,或许是自己没有给予 Rust 足够的机会。他决定再使用一段时间 Rust。使用过后,他终于能够自信地给出结论:

这门语言就是糟透了!!!

Rust 差在哪里?

Austin 用了几个词来形容来总结自己对 Rust 的厌恶:糟糕、冗长、难以理解的语法和语义。

 一个复杂的 Rust 函数示例

Austin 吐槽道,说 Rust 语义不糟糕的人都是在撒谎。如果没有一个非常强大的大型语言模型,在写函数的时候就会有很多事情做不成。他不想花 90 分钟去弄清楚 run_transaction 函数中的 where 子句。最终,他完全放弃了使用辅助函数的想法,因为根本无法让代码编译通过。人们所说的 Rust 最大的优点(严格的编译器来消除错误)反而是 Rust 最大的缺点。

Austin 举了个例子,如果在 Go 中编写这个完全相同的函数,代码大概会下图这样。虽然函数的核心结构保持相对不变, 但代码能直接按照预期运行,不需要做过多复杂的调整、技巧或反复的尝试。 

 Go 实现的函数 

Rust 在错误处理方面似乎有些优势。只要你避免使用不安全的 unwrap 来减少运行时错误(例如空指针异常),就可以确定代码会运行并持续运行。真的是这样吗?Austin:不!

他指出当数据出错或发生意外时,开发者很难快速诊断问题,因为错误信息往往不够直观,开发者可能很难弄明白错误的根本原因。他自嘲,可能自己没有找到启用堆栈跟踪的正确方法,这让调试变得更加困难。

Austin:我的堆栈跟踪在哪儿??? 

相比之下,Python 能够提供堆栈跟踪,精确告诉你发生了什么,甚至到行号。Austin 表示,就算是 Go 语言,也有 errors.Wrap (...),让你能够查看整个错误堆栈。显然,这是 Rust 的设计缺陷。

除了 Rust 的设计缺陷,社区氛围也是难评。Austin 表示,社区不能接受别人提出 Rust 有缺陷这个观点。发表的看法会遭到攻击,提出的问题也只能收获阴阳怪气。

Austin 在 Rust 社区中收到的「有用」回复

你有用过 Rust 吗?在评论区分享一下你的体验吧。

拓展阅读:

参考链接:
https://www.prisma.io/blog/prisma-orm-manifesto
https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/
https://spectrum.ieee.org/top-programming-languages-2024
https://medium.com/codex/i-spent-18-months-rebuilding-my-algorithmic-trading-in-rust-im-filled-with-regret-d300dcc147e0

© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:[email protected]

说Rust是最佳选择有点绝对了,毕竟技术选型要看具体情况。C++性能也很强,安全性方面可以通过现代C++的一些特性和规范来提升,只是需要开发者更小心谨慎。此外,像Zig、Nim等新兴语言也值得关注,它们同样注重性能和安全,并且在某些方面比Rust更易用。

性能和安全本身就有点矛盾,Rust追求内存安全,肯定要牺牲一些性能。如果项目对性能要求极高,那C/C++可能还是更合适,但需要严格的代码审查和测试来保证安全。如果安全是首要考虑因素,Rust确实是个不错的选择,但学习曲线比较陡峭,团队成员都需要有一定的Rust经验才能保证项目顺利进行。

“文章中提到的开发者在Rust社区遇到的不友好经历,是否是个例?Rust社区的整体氛围如何?”,对于这个问题,我的看法是Rust的语法和语义比较复杂,代码可读性可能会受到影响。如果项目需要长期维护,这可能会增加维护成本。此外,Rust的编译时间比较长,这可能会影响开发效率。

我感觉Rust社区对新手确实不太友好,特别是对那些不熟悉Rust的开发者。他们更关注代码的正确性和效率,而不是解释为什么这样写。如果你的代码不符合Rust的规范,可能会受到一些批评,但这也可以帮助你更快地学习Rust。

我觉得一个社区的氛围是由各种各样的人组成的,肯定会有友好的也有不友好的。文章中提到的开发者经历可能是个例,也可能反映了Rust社区的某些问题。我个人接触过的Rust开发者都挺热心的,也很乐于助人。不过,每个社区都有自己的文化和规范,新人加入时可能需要适应一下。

“抛开技术层面,从项目的长期发展来看,选择Rust作为主要开发语言有哪些潜在的风险和挑战?”,对于这个问题,我的看法是尽管Rust有很多优点,但它并非所有项目的最佳选择。选择Rust作为主要开发语言需要仔细权衡项目的长期发展目标、团队的技术能力和潜在的风险。如果项目对开发速度和成本比较敏感,或者团队缺乏Rust经验,那么选择Rust可能不是一个明智的决定。

任何一个技术社区都会存在一些不友好的声音,这很正常。Rust社区对代码质量要求比较高,所以可能会对一些不规范的代码提出批评。但这并不代表整个社区都不友好,很多Rust开发者都非常乐于分享和交流技术,关键在于你如何与他们沟通。

关于这个问题,我的看法是,虽然Rust在性能和安全方面表现出色,但它并非唯一的选择。像Go、Java等语言在特定场景下也能兼顾性能和安全。Go的并发特性和快速编译速度很适合高并发服务,Java则拥有庞大的生态系统和成熟的垃圾回收机制,可以保证应用的稳定性和安全性。最终选择哪种语言,还是要根据项目的具体需求来决定。

“如果一个项目既要追求性能又要考虑安全性,Rust真的是最佳选择吗?有没有其他语言可以兼顾这两方面?”,对于这个问题,我的看法是Rust学习曲线陡峭,团队成员的招聘和培训成本会比较高。如果团队中缺乏经验丰富的Rust开发者,可能会影响项目的开发进度和代码质量。另外,Rust的生态系统相对较新,一些库和工具还不够成熟,这可能会给项目带来一些风险。