As a user of both libcurl (haven’t followed it’s development for years though) and hyper, I’d say either commit to making hyper the default at some point and make that a priority, or drop it altogether. And since there is no intention/plan to do the former, then latter does indeed follow logically.
Hyper doesn’t seem to have a roadmap nor an easy way for newcomers to just pick up stuff and get going. It looks more like a “ready TM” project that’s already hit EOL and is being maintained. Even after reading the blog post I can’t tell what has to be done. There are a bunch issues, but they seem to be a bunch of bugs and refactoring.
Maybe if it looked more like something that needed help, it would get it?Hyper isn’t supposed to be what you use if you just want to make a web request or serve some content. You use request and Axum/actix/warp/rocket for that respectively.
It’s supposed to handle the conversion between bytestream and structs representing http. It is really good at that.
To be fair, the latest stable version of hyper until a few months ago (pre v1) did offer usable high level API. What you describe only strictly applies to v1 hyper which hasn’t been around (in stable release form) for long.
On the other hand, I’m not sure why the parent commentator thinks lack of too much core development is a bad thing, or why they think hyper “needs help”.
Hyper itself does work quite well in Rust and is the basis for the vast majority of Rust web frameworks, I just don’t really see a use case for wrapping it in the curl API.
I think it’s used because the author of curl is moving towards rust and doing it piecemeal. Although curl is well-tested and battle-tested, it’s still written in a memory unsafe programming language, which I think was the motivation.
Well, the author of curl is the Daniel Stenberg suggesting its removal here.
Hyper was the standard for Rust web servers way before it was used by curl for anything.
That’s probably why the curl author chose it.