> We have shipped hyper support in curl labeled EXPERIMENTAL for several years by now, hoping to attract attention and trigger the experimental spirit in users out there. Seeing so many people seem to want more memory-safety, surely the users would come?

This analysis seems off. Memory safety isn't a feature users will explicitly ask for or opt-in to. What users want is software that isn't buggy, and they just sort of ambiently expect it. A "Rust backend" is pretty meaningless to users, a bit like expecting users to pass a --dont-be-buggy flag to every invocation of the CLI tool.

As a user, I'd have questions like: if this backend is better then why isn't it the default? Why do I have to make a decision at all? I just want an HTTP library/tool that doesn't let me get hacked, how it achieves that is none of my concern really. Whether that's done using Rust or not isn't something that should appear in the user interface.

I don't really like the idea of mixing languages in projects, be it curl or the linux kernel, doesn't matter. If an already established and proven language was already being used for such a long time successfully, that should remain the language of the project. Forks or entirely new / independent projects may be created with whatever new language is being hyped up, and that is totally fine / should be the way to go. In the end, more harm will come from forcing these new languages into long-established projects than benefits.

I think there was little traction in curl, because Rust users can just use hyper directly.

https://lib.rs/curl is used in 1000 packages, https://lib.rs/hyper is in 21,000 packages.

Curl is big and supports lots of protocols, but Rust doesn't need a one-stop-shop for all of them. HTTPS covers majority of uses, and Rust has separate packages for mail, ftp, websockets, etc.

One thing I've wished for in curl is for the backends ("handlers") to be more pluggable. This would solve a packaging problem we have in Fedora where we'd prefer to distribute a core curl with backends packaged as subpackages, so that programs that only need (eg) http support would only need to depend on curl-handler-http and curl-core. At the moment the actual solution is to compile separate curl and curl-minimal packages where curl-minimal removes the lesser-used backends, and you have to choose, system-wide, which one to install.

This plus a stable ABI for handlers would also solve the writing backends in other languages problem because another team could contribute a Rust / hyper handler separately.

(I'm sure Daniel has solid reasons for not doing this, not to mention that it's a bunch of work which no one is volunteering to do.)

As a rust dev I wish we had more choice of http libraries then hyper. I have a lot of respect for the author but I consider this library a hot mess of over complicated abstraction. If you tried to use hyper recently you know what I mean, just to do anything you need 4 sister crates. The internals of hyper are both hard to read and opiniated in way that makes me swear heavily every time I have to touch it.

> We had to rethink and reassess several implementation details when we aligned HTTP behavior with hyper. libcurl parses and handles HTTP stricter now. Better.

That would be interesting to dig in deeper. Wish they did that in the article. Or linked an article where they do.

They removed a backend. Rustls and QUIC are still an option

I'm curious for more details about which tests were hard to align and why

imo rust is a great language, but the leadership/project setup is very untrustworthy.

The systemic security problems of cargo package distribution opens the door for state-sponsored threat actors to performing supply chain attacks. And when asked about these issues the only people who will comment using their real identities are based in China.

The security issues in the rust development experience are well-documented since several years, so my summary at [1] was no news to them.

But if you offer things like rustfmt, rustdoc, and a nice-to-use package distribution platform like cargo.io you should be a bit more concered with security imo.

Their lax attitude to these issues and substantial corporate interests not only from US-based but also China-based companies might be good for funding but for me raises many questions.

[1] https://github.com/bf/rust-security-problems

https://github.com/ducaale/xh is where it's at, haven't used curl in years.