Projects of similar size in JS have hundreds of dependencies, so 52 really isn't a lot

Or because JS is and was a hype and is full of people marketing their names through many easy, small packages.

Rust has this same problem. (Although you could make the argument that this specific state of things was explicitly chosen in Rust's case.)

Well, looking at various crates pulling in lots (dozens) of dependencies, I'd say crates.io is clearly moving somewhere into that direction of microlibraries with extensive code reuse.

I only encounter this in Rust when doing anything web-related. There's quite a lot of prominent authors who go out of their way to reduce their dependencies by any means necessary (e.g. https://github.com/tokio-rs/tokio/pull/1324 , which is a notably extreme case).

> I only encounter this in Rust when doing anything web-related.

It's probably because anything web-related requires so many things no readily available in the language or in the standard library: anything from databases (sometimes different breeds of databases) to templating to serialisation (possibly multiple types of serialisation) to rest or graphql to...

Just serialisation (which is almost invariable Serde) will pull in at least 54 dependencies (if you only use serde and serde_json). A framework such as rocket which provides all that, and more, will pull in ... 332 dependencies :)

Edit: Calculation is invalid, see https://news.ycombinator.com/item?id=24024671

> Just serialisation (which is almost invariable Serde) will pull in at least 54 dependencies (if you only use serde and serde_json).

What is this number referring to? Serde + serde_json with all their transitive dependencies is maximum 12 crates (for someone who has enabled all optional features), though in typical usage it's 9 crates: serde, serde_derive, serde_json, syn, quote, proc-macro2, unicode-xid, itoa, ryu. I haven't figured out how you got to 54.

I ran `cargo tree -e all | wc -l`. Now I realise that's not a proper way to do it :-/

Looks like `cargo metadata --format-version=1 | jq -r ".packages|map(.name)|.[]"` is the way to do it.

- 10 for serde + serde_json

- 88 for rocket only

The trouble with monolithic crates is that they're monolithic. People complain about the massive amount of code they have to pull in just for a few functions, and the effect this can have on compile times.

The trouble with small crates is they're small. People complain when the number of dependencies grows larger and mockingly reference "leftpad".

The issue with leftpad wasn't that it was small. The issue was that so much production code relied on it not going away, despite npm letting the author make it go away.

Yes, the problem that broke everything was what you mentioned. But what struck everyone more was that this all happened because of a few line function that should have obviously never been a dependency in any sane project.

The security/operational issue may have been that the author was able to break production code, but the simplicity of the function is what made it extremely funny.

If people pull a massive amount of code to use a few functions, the problem is not the size of the code, the problem is the lazyness of the developer who doesn't want to write 3 functions.

Same for leftpad-like packages, I don't need a dependency to a single function that I can rewrite myself. Especially if I'm not writing open-source software and I have to audit the licenses of my dependencies.

Software development is a matter of trade-offs, you get what you choose, people should not be complaining about that.

If you're adding encryption support, you're likely adding openssl which brings hundreds of cryptographic primitives you're not going to use. Are you lazy because you didn't write your own RSA? (you can do it in ~3 functions)

That generalisation didn't work well, because as you say - it's about tradeoffs.

I can’t implement RSA in the amount of time it takes me to Google the name of an RSA library.

I can implement left pad faster than it would take me to Google the name of the library, check whether it actually does what I want and then add it to my package manifest as a dependency.

The amount of work needed to write a secure implementation of RSA (you would surely need a library like gmp to handle big numbers) is not worth my time, I would gladly trade that against some download/compilation time.

The same goes for efficient map/reduce framework or even a key/value database (what's wrong with using BerkleyDB/SQLite instead of writing your own storage format?).

I need to serialize user-supplied data ? I'm gonna use a library that will handle edge cases I can't think about.

But I'm not gonna use SpringBoot only for its logging facility, or Django only for its ORM, or a BNF parser generator to parse "hello world".