都推进到95%了，为什么curl还是放弃基于Rust开发了四年的HTTP后端替代（rust写前端）
今天给各位分享
整理 | 燕珊curl 放弃对 Hyper Rust HTTP 后端的支持“实验结束了我们努力了，但还是失败了”近日，知名开源项目 curl 的创始人 Daniel Stenberg 正式发文宣布，将放弃对基于 Rust 编写的 Hyper HTTP 后端的支持，并彻底移除相关代码
“四年前，我们开始在 curl 中添加对另一种 HTTP 后端的支持它将使用一个基于 Rust 编写的库，名为 Hyper我们的想法是引入一种替代的 HTTP 内部实现，让 curl/libcurl 使用它来代替本地实现。
”Stenberg 在博客中写道然而，这场实验在历经四年的努力后，以失败告终完成 95% 的工作只是开始？这一尝试始于 2020 年，由 ISRG（Let’s Encrypt 背后组织）资助当时的目标是通过 Rust 的内存安全特性，为 curl 用户提供一个更安全的 HTTP 后端实现。
Stenberg 在早期的博客中写道“通过 Hyper，我们能够让更多代码运行在内存安全语言中，而非完全依赖 C”尽管实验已经推进了一大半，甚至让 Hyper 后端通过了几乎所有测试用例，但如同 Stenberg 在最新的博文中所述，“
我们完成了 95% 的开发工作，然而，最后那‘百分之几’的挑战，还是让我们不得不认输，放弃这个实验”目前来看，实验失败的两大关键原因如下：几乎没人有这需求：curl 的用户对 Hyper 没有兴趣；Hyper 的用户也不太关心让它兼容 curl。
缺乏同时精通 C 和 Rust 的开发者来推进：Hyper 是用 Rust 写的，而 libcurl 库（curl 背后的“引擎”）是用 C 写的，需要一个“胶水层”来把它们连接起来这需要开发者不仅对两种语言精通，还要深入理解它们的架构和协议，但目前没有合适的人去做这件事。
此外，早在 2020 年开始这个实验时，Stenberg 就提到过“Hyper 没有 C API”是一个棘手的挑战停滞与反思：Hyper 成为“负担”在今年 4 月的另一篇推文中，Stenberg 就预示过这次实验的结局，他提出了发人深省的问题：“Hyper 支持是否值得继续？”——当时，Hyper 后端的开发工作已陷入停滞，过去半年内几乎没有人主动对其进行功能改进或优化。
与此同时，用户对 Hyper 的需求仍然冷淡技术上，Hyper 后端的开发过程中还出现了多次反向调整例如，例如，由于对 Hyper API 集成方式的理解偏差，而不得不移除对 HTTP/2 的支持，这直接导致无法正确实现 HTTP/2 的功能。
更大的问题在于，社区用户的需求和兴趣严重失衡：当下 Rust 用户更愿意直接使用 Hyper，而不是帮助让它支持 C 项目；而 curl 的现有用户对 Hyper 几乎没有兴趣社区中这两类用户的交集太小，已经无法为 Hyper 后端的持续开发提供足够的支撑。
面对多重困难，Stenberg 开始反思：“Hyper 的支持是否已经从一种探索创新的尝试，变成了拖累改进的负担？”显然，继续维护这一功能的成本已经超过了它的实际价值既然在短、中期内都看不到完成的希望，与其继续耗费资源，不如果断放弃——移除这部分代码，不仅可以大幅简化项目结构，还能提高整体的灵活性，为 curl 的未来发展留出更多空间。
用其他语言重写 curl？也几乎不可能或许会有人提问，当初为什么不直接用 Rust 重写 curl 呢？Stenberg 早就明确表示，这从来不在他们的计划之中一方面，curl 是一个老牌开源软件，已经运行了 25 年。
对于 libcurl 用户来说，稳定的接口（API）、应用二进制接口（ABI）、一致的行为，以及文档中定义的所有功能选项，都是不可动摇的基础重写代码不仅意味着要重新开发所有功能，还需要确保新版本完全兼容旧版，这对任何项目来说都是一项巨大而复杂的挑战。
即使是那些考虑过这样做的大型企业，最终也都放弃了这个想法与此同时，Stenberg 等人也深知，curl 必须不断引入新功能，才能跟上技术的发展步伐于是，Hyper 后端支持方案成为他们探索的方向虽然 Hyper 实验以失败告终，但它对 curl 和 Hyper 项目都带来了积极影响。
Stenberg 表示，curl 在与 Hyper 集成的过程中，改进了自身对 HTTP 的严格性，并优化了代码结构，而 Hyper 则通过与 curl 的合作获得了宝贵的反馈，进一步提升了自身的稳定性和性能。
他强调：“虽然 Hyper 已被移除，但我们依然对未来引入 Rust 或其他语言的安全后端持开放态度与 2020 年那会相比，我们现在已经拥有了更好的内部架构可供借鉴只要用户需求足够明确，并且有足够的资源支持，我们还可能会重新尝试类似的整合。
”尽管 Hyper 被放弃，curl 仍然在推进对两个 Rust 编写的后端的支持：：rustls（用于 TLS）和 quiche（用于 QUIC 和 HTTP/3），它们被认为比 Hyper 更易于维护。
据悉，Hyper 的相关代码已于 2024 年 12 月 21 日从 curl 的代码库中删除，并将在 2025 年 2 月发布的 curl 8.12.0 版本中完全失效。
