四年苦功付诸东流，curl弃用Rust后端

引言

开源世界再次上演了一出令人唏嘘的剧目。知名网络传输工具 curl 的创始人 Daniel Stenberg 近日宣布，经过四年的努力，他们决定放弃基于 Rust 语言编写的 Hyper HTTP 后端替代方案。这个项目一度推进到 95% 的完成度，却最终因多重挑战而宣告失败。这一事件不仅引发了技术社区的广泛关注，也引发了人们对开源项目发展、技术选型以及社区协作等问题的深刻思考。

背景：Curl 的 Rust 化尝试

Curl，这个在互联网世界中无处不在的命令行工具和库，以其强大的网络传输能力和广泛的应用场景而闻名。然而，其核心代码库 libcurl 长期以来使用 C 语言编写，这在内存安全日益受到重视的今天，显得有些力不从心。为了解决这一问题，并尝试引入更现代的编程范式，curl 团队在 2020 年启动了使用 Rust 语言重写 HTTP 后端的实验。

Rust 语言以其内存安全、高性能和并发性而著称，被认为是构建安全可靠系统的理想选择。Hyper，一个用 Rust 编写的 HTTP 客户端/服务器库，成为了 curl 团队的首选。他们的目标是让 curl/libcurl 使用 Hyper 作为其 HTTP 内部实现，从而在保证功能的同时，提高安全性。这项计划得到了 ISRG（Let’s Encrypt 背后的组织）的资助，也一度被视为 curl 未来发展的重要一步。

实验的推进与挑战

在过去的四年里，curl 团队在 Hyper 后端集成方面取得了显著进展。他们完成了 95% 的开发工作，几乎所有的测试用例都通过了。这意味着，在技术层面，Hyper 后端已经具备了替代现有 C 语言后端的潜力。然而，正如 Stenberg 在博客中所言，“最后那‘百分之几’的挑战，还是让我们不得不认输，放弃这个实验。”

这个“百分之几”的挑战，并非单纯的技术难题，而是由一系列复杂的因素交织而成：

用户需求不足： Curl 的用户对 Hyper 后端并没有表现出强烈的兴趣。许多用户仍然满足于现有的 C 语言实现，并没有迫切的需求去切换到 Rust 后端。另一方面，Hyper 的用户也主要集中在使用 Hyper 库本身，而不是将其集成到 curl 这样的 C 语言项目中。这种需求上的错位，导致了 Hyper 后端缺乏足够的社区支持。
缺乏跨语言开发者： Hyper 是用 Rust 编写的，而 libcurl 库是用 C 编写的。要将两者集成，需要一个“胶水层”来连接它们。这需要开发者同时精通 C 和 Rust 两种语言，并且深入理解它们的架构和协议。然而，能够胜任这项工作的开发者非常稀缺。这使得 Hyper 后端的开发和维护变得异常困难。
技术集成难题： Hyper 本身并没有提供 C API，这给集成带来了额外的挑战。在集成过程中，curl 团队不得不进行多次反向调整，甚至不得不移除对 HTTP/2 的支持，这直接导致无法正确实现 HTTP/2 的功能。这些技术上的难题，进一步加剧了开发难度。
社区协作失衡： Rust 社区的开发者更倾向于直接使用 Hyper，而不是帮助其支持 C 项目。而 curl 的用户则对 Hyper 几乎没有兴趣。这种社区协作的失衡，使得 Hyper 后端的开发缺乏足够的动力。

停滞与反思：Hyper 成为“负担”

随着时间的推移，Hyper 后端的开发工作逐渐陷入停滞。在过去的半年里，几乎没有人主动对其进行功能改进或优化。与此同时，用户对 Hyper 的需求仍然冷淡。Stenberg 开始反思，Hyper 的支持是否已经从一种探索创新的尝试，变成了拖累改进的负担。

他意识到，继续维护这一功能的成本已经超过了它的实际价值。与其继续耗费资源，不如果断放弃。移除 Hyper 后端代码，不仅可以大幅简化项目结构，还能提高整体的灵活性，为 curl 的未来发展留出更多空间。

为何不直接用 Rust 重写 Curl？

在得知 curl 放弃 Hyper 后端的消息后，一些人可能会提出疑问：既然如此，为什么不直接用 Rust 重写整个 curl 呢？Stenberg 早就明确表示，这从来不在他们的计划之中。

Curl 是一个拥有 25 年历史的成熟开源项目。对于 libcurl 用户来说，稳定的接口（API）、应用二进制接口（ABI）、一致的行为，以及文档中定义的所有功能选项，都是不可动摇的基础。重写代码不仅意味着要重新开发所有功能，还需要确保新版本完全兼容旧版，这对任何项目来说都是一项巨大而复杂的挑战。即使是那些考虑过这样做的企业，最终也都放弃了这个想法。

此外，curl 必须不断引入新功能，才能跟上技术的发展步伐。Hyper 后端支持方案成为了他们探索的方向。虽然 Hyper 实验以失败告终，但它对 curl 和 Hyper 项目都带来了积极影响。curl 在与 Hyper 集成的过程中，改进了自身对 HTTP 的严格性，并优化了代码结构。而 Hyper 则通过与 curl 的合作获得了宝贵的反馈，进一步提升了自身的稳定性和性能。

未来的方向：开放与谨慎

尽管 Hyper 被放弃，curl 仍然在推进对两个 Rust 编写的后端的支持：rustls（用于 TLS）和 quiche（用于 QUIC 和 HTTP/3）。这两个后端被认为比 Hyper 更易于维护。

Stenberg 表示，他们仍然对未来引入 Rust 或其他语言的安全后端持开放态度。与 2020 年那会相比，他们现在已经拥有了更好的内部架构可供借鉴。只要用户需求足够明确，并且有足够的资源支持，他们还可能会重新尝试类似的整合。

结论：开源的挑战与启示

Curl 放弃 Hyper 后端实验的案例，为开源项目的发展提供了宝贵的教训：