Stenberg: Dropping hyper

[Posted December 21, 2024 by corbet]

Curl maintainer Daniel Stenberg announces that the curl project will be dropping hyper, its experimental HTTP backend written in Rust, due to lack of developer interest.

While the experiment itself is deemed a failure, I think we learned from it and improved curl in the process. We had to rethink and reassess several implementation details when we aligned HTTP behavior with hyper. libcurl parses and handles HTTP stricter now. Better.

Perhaps it needed more publicity?

Posted Dec 22, 2024 20:49 UTC (Sun) by vadim (subscriber, #35271) [Link]

I had no idea this even existed, and there appear to be about two mentions total of it here on LWN.

Experimental?

Posted Dec 23, 2024 8:35 UTC (Mon) by taladar (subscriber, #68407) [Link] (3 responses)

I don't really see how they expected anything else.

Those who want to use Rust won't use curl. Those who want to use Rust from C also won't have a good reason to add curl into the mix. Of the remaining people, who would opt for something marked experimental over something marked stable? Was it even compiled in by default? Most users don't compile their own version of curl.

Experimental?

Posted Dec 23, 2024 13:25 UTC (Mon) by Baughn (subscriber, #124425) [Link]

I might have used it, but I had no idea it existed. And yes, if I were writing a rust program I would have used hyper directly. (And have.)

Experimental?

Posted Dec 23, 2024 16:20 UTC (Mon) by bagder (guest, #38414) [Link]

curl is an architecture with "core transfer engine" using N different backends, mostly powered by third party libraries, for TLS, SSH, QUIC/HTTP/3, compression, IDN and more.

For TLS for example, curl support twelve different libraries. For SSH, three. For QUIC, four. Two of the libraries supported are written in rust.

It was not a stretch, in my mind, to add support for multiple backends for HTTP/1 and HTTP/2 as well, and then yet another one of the third party libraries could be one written in rust.

But clearly it did not work out. curl still supports rust libraries for TLS and for QUIC+HTTP/3.

/ Daniel

Experimental?

Posted Dec 24, 2024 0:17 UTC (Tue) by intgr (subscriber, #39733) [Link]

> Those who want to use Rust won't use curl. Those who want to use Rust from C also

Erm? To me the benefit seems obvious.

Those who are already using C and curl could benefit from a more secure implementation, which interacts with potentially untrusted services over the internet, with no changes needed.

Poor messaging

Posted Dec 23, 2024 18:26 UTC (Mon) by proski (subscriber, #104) [Link]

The intention was perhaps to mark hyper as "experimental" to indicate that something was actively working on it. However, there are plenty of "experimental" projects in the world that are simply unfinished, and nobody is working on them anymore.

As Yoda said in the Star Wars "Do or do not. There is no try."

One distribution did use it

Posted Dec 26, 2024 11:47 UTC (Thu) by Tobu (subscriber, #24111) [Link]

Serpent OS did enable that backend in response to a call by the hyper maintainer last month: Mastodon post (scroll to "and done").

Until this announcement, I had only been aware of the Rust Quic backend (quiche+rustls), because I've been motivated to build curl with HTTP/3. I hope this hyper backend can come back. Curl is very widely used, and it has a stable interface, so this would be impactful, both for the CLI tool and library invocations.

ISRG

Posted Dec 28, 2024 0:14 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

It would be interesting to know whether ISRG learned something from this, about how to best direct resources to achieve your intended impact. "What if curl used Rust?" sounds like a good idea, but actually the impact was negligible, basically as you'd expect it helped Daniel express what he meant† but didn't much make the software people use safer.

† which is usually what happens when you write software in Rust rather than C, not least because you have a real type system so you will naturally reach for Option<OwnedFd> in Rust to express either a file descriptor or not, instead of int in C, even though the resulting machine code is identical.