alt Hacker NewsI don't agree with some points, but I share the feeling in terms of "failed promises".
The fact that most well-known Rust crates are becoming huge bloat are becoming a problem to me, which is something that has been critized years again by the community itself.
As an example, I still do not understand why simple HTTP crates require more than 50 to 70 dependencies to execute a simple GET call...
Replies
So let me get this straight. You want the benefit of being able to re-use other peoples' codebase by using an HTTP crate you didn't write. But you don't want those people to also use that benefit of depending on other crates.
Insisting that you should depend on code which itself has no dependencies is a bit hypocritical if you ask me. If you want a simple HTTP crate that doesn't have dependencies, you should follow your own philosophy of not using other crates and write it yourself.
> As an example, I still do not understand why simple HTTP crates require more than 50 to 70 dependencies to execute a simple GET call...
This is what you get with package managers.
I think it's clear to me that Rust needs to start admitting more into the STD to help with this and increase the consistency across the ecosystem.
> As an example, I still do not understand why simple HTTP crates require more than 50 to 70 dependencies to execute a simple GET call...
Looking at ureq [0], for example, its direct non-build/non-dev dependencies are (counting duplicates):
- base64
- flate2 (4 transitive dependencies)
- log
- percent-encoding
- rustls (26 transitive dependencies)
- rustls-pki-types (1 transitive dependency)
- ureq-proto (7 transitive dependencies)
- utf-8
- webpki-roots (2 transitive dependencies)
The vast majority of the raw dependency count comes from Rustls and related crates, and I'd imagine reimplementing a TLS stack would be somewhat out of scope for an HTTP crate. I'm not sure there's much room for substantial reductions in dependency count otherwise.
[0]: https://github.com/algesten/ureq