3 ms·

Those dependencies aren't recompiled every time you change something. They will only impact your initial build or a clean build on a CI/CD system. Raw dependen

Those dependencies aren't recompiled every time you change something. They will only impact your initial build or a clean build on a CI/CD system. Raw dependency counts can be shocking for those coming from other languages where pulling in a dependency is an uncommon operation, but it's not a bad thing. I'd rather have my HTTP client library re-use popular, tested packages for things like decoding JSON, handling TLS, working with IP addresses, and other common tasks. I don't think it would be better to have every package roll their own versions of all of those common pieces. You can browse the dependencies of reqwest here: https://crates.io/crates/reqwest/0.11.4/dependencies https://crates.io/crates/reqwest/0.11.4/dependencies Notably, several of the big dependencies are maintained by the same person who maintains reqwest. It's a common practice with Rust crates to split a project into reusable parts. Reqwest uses hyper (http client), http, http-body, mime, url, and several other crates that are owned by the person who owns the reqwest crate. If we instead mashed all of those dependencies together into a single crate it would appease the people who don't like seeing high dependency numbers, but it wouldn't really make the product any better. It would make it harder to re-use the individual pieces, though. > I just went back to go, which can do the crazy obscure task of making an http request without requiring 100 external dependencies. Go is famous for including HTTP utilities in the standard library. If I was building a simple app that made HTTP requests and little more, I'd probably pick Go as well. Or Python. Or you could have searched for a minimal HTTP request crate ( https://github.com/algesten/ureq https://github.com/algesten/ureq ) designed to be small instead of using the most full-featured crate. Or you could have searched for Rust libcurl bindings ( https://github.com/alexcrichton/curl-rust https://github.com/alexcrichton/curl-rust ) to use an old standby. If your goal is to reach for something quick and easy with batteries included and minimal external dependencies, Rust is not a good choice. Doesn't mean Rust is "bad", but it's not the right tool for every simple job. You also can't just pick the most popular crate and assume it's exactly what you want.

smoldesu 5y ago
> It's a common practice with Rust crates to split a project into reusable parts. Precisely this. Rust is not the same as Go or Java or Python: it's still a fairly low-level language. Standard practice is to build lower-level components (like http parsing and url crates) that are abstracted over by more 'friendly' crates (like reqwest). It's jarring, and certainly different from a lot of other languages, but it's a testament to the language's flexibility in my eyes.
- masklinn 5y ago
  An other factor is that the unit of building / concurrency in compilation is the crate. So splitting a crate into 15 sub-crates (which could be reused independently) increases parallelism.

smoldesu 5y ago

> It's a common practice with Rust crates to split a project into reusable parts. Precisely this. Rust is not the same as Go or Java or Python: it's still a fairly low-level language. Standard practice is to build lower-level components (like http parsing and url crates) that are abstracted over by more 'friendly' crates (like reqwest). It's jarring, and certainly different from a lot of other languages, but it's a testament to the language's flexibility in my eyes.

masklinn 5y ago
An other factor is that the unit of building / concurrency in compilation is the crate. So splitting a crate into 15 sub-crates (which could be reused independently) increases parallelism.