Hacker News Reader

Comment by Sytten | Hacker News Reader

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.

View on HN

hyper more like a build block rather than a tool you can directly use, maybe you just should use other libraries which built on the hyper

Yeah, I'm using the curl wrapper crate for a Rust re-write of a C++ HTTP monitoring app I'm re-doing, because there's nothing I can find in the Rust ecosystem that even comes close to what libCurl exposes in terms of functionality and control (i.e. things like all the different timing numbers).

The wrapper crate hasn't got everything exposed for the Easy interface (I'll probably be submitting PRs to expose some missing stuff at some point), but seems good enough for me.

Only issue really I've found so far is that heap fragmentation seems orders of magnitude higher than the C++ version, and so memory useage grows quite alarmingly, but from heaptrack, that all seems to be from within openssl, with things like this (a rediculous number of heap allocations per request):

https://github.com/openssl/openssl/issues/14837

but I'm not sure why the older C++ version doesn't suffer from the same issues as it's doing the same thing with HTTPS requests and is also using openssl, so I still need to look into that...

Currently doing:

unsafe { libc::malloc_trim(0); }

every 5 minutes keeps the memory use under control, but again, I don't need to do that in the C++ version, so there's some difference somewhere in the libcurl stack between the two...

There is hundreds if not thousands of rust crates for http to choose between. `reqwest` is just one of many other popular alternatives, all built for different sorts of tradeoffs.

Most of them are built on top of hyper, including reqwest [0] (not a bad thing, they're just still hyper).

I personally wouldn't even consider hyper as an HTTP client for use in most projects, but reqwest adds a much more approachable API on top of hyper.

[0] https://github.com/seanmonstar/reqwest/blob/master/Cargo.tom...

And to get a simple https request you end up with about 200 crates in your tree

This is an (unfortunate?) part of the Rust ecosystem. Reminds me of the JS/NPM mess. I think it is a bit better in the Rust world, but I’m still undecided if it is acceptable to have so many crate dependencies for conceptually simple programs.

No, there are smaller crates out there that enable a simple https request with far less crates.

Much of that is due to not needing Tokio & co.

Yes.

Part of the problem is there are so many, which do you choose?

I found one (I forget the name to protect the guilty) but my simple use case broke it.

I reached out to the authors, very helpful, I think they fixed it.

But by then I had moved on (time is money)

I sucked it up and went with importing all the tokio stuff I did not need (I absolutely did not need, almost no one does)

Rust has painted itself into a corner. A really very good idea at its core, almost all of it is really terrific, but some corner cases like these make it very hard to take advantage of it

Deciding which one to try isn't hard at all: `ureq` is the de-facto small HTTP library that you'd reach for, and you're likely to find people referencing it within 2 minutes of Googling. The only thing `ureq` was missing that's common (ish) was a happy eyeballs implementation, and they've recently handled it.

This just isn't a significant problem at all.

> Deciding which one to try isn't hard at all

Nonsense.

If you are steeped in HTTPS clients for Rust, maybe, but I can tell you from personal experience that coming fresh to https://crates.io/search?q=https%20client and friends is overwhelming

A few minutes in Google would've saved you that confusion, same way it works for any other package manager.

Reply on news.ycombinator.com