3 ms·

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 comp

by Sytten 2y ago

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.

diggan 2y ago
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.
- jjice 2y ago
  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.toml https://github.com/seanmonstar/reqwest/blob/master/Cargo.tom...
- worik 2y ago
  And to get a simple https request you end up with about 200 crates in your tree
  - jdiez17 2y ago
    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.
  - Klonoar 2y ago
    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.
    - worik 2y ago
      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
      - Klonoar 2y ago
        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.
        worik 2y ago
        > 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 https://crates.io/search?q=https%20client and friends is overwhelming
        Klonoar 2y ago
        A few minutes in Google would've saved you that confusion, same way it works for any other package manager.
uonr 2y ago
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
pixelesque 2y ago
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 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...

by Sytten 2y ago

diggan 2y ago

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.

jjice 2y ago
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.toml https://github.com/seanmonstar/reqwest/blob/master/Cargo.tom...
worik 2y ago
And to get a simple https request you end up with about 200 crates in your tree
- jdiez17 2y ago
  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.
- Klonoar 2y ago
  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.
  - worik 2y ago
    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
    - Klonoar 2y ago
      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.
      - worik 2y ago
        > 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 https://crates.io/search?q=https%20client and friends is overwhelming
        Klonoar 2y ago
        A few minutes in Google would've saved you that confusion, same way it works for any other package manager.

uonr 2y ago

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

pixelesque 2y ago

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 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...