声明:本文来自微信公众号“机器之心”（ID:almosthuman2014），作者:杜伟授权站长之家转载发布。
作为一门系统编程语言，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月发布的 curl8.12.0版本中将不会留下任何痕迹。
不过，虽然 hpyer 被移除了，Stenberg 对未来引入 Rust 或其他语言编写的安全后端持开放态度。未来会采用一些不一样的做法，毕竟与2020年开始 hyper 时相比，他们现在拥有了更好的内部架构。
无独有偶，在12月初，另一个开源数据库工具链项目 Prisma 也表态将从 Rust 迁移至 TypeScript，以追求更好的插件和扩展生态。
声明中写道:Prisma 的架构历来限制社区贡献，其核心功能（例如查询解析、验证和执行）由 Rust 引擎管理，而这对于专注于 TypeScript 的社区来说是不透明的。因此决定将 Prisma 的核心逻辑从 Rust 迁移到 TypeScript，并重新设计 ORM，以使定制和扩展更容易。
近几年 Rust 语言正在强势崛起，在一些编程语言排行榜中的排名一直在攀升，比如2024IEEE 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 吗?在评论区分享一下你的体验吧。
拓展阅读:半小时入门 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
ChatGPT源码推荐：小狐狸ChatGPT付费创作系统完全开源源码