Firm disagree.

Sylvain Kerkour described the problems Rust faces by having a limited standard library:

"The time has come for Rust to graduate from a shadow employment program in Big Tech companies to a programming language empowering the masses of engineers (and not just "programmers") wanting to build efficient and robust sfotware.

What crypto library should we use? ring, RustCrypto, rust-crypto (don't use it!), boring, aws-lc-s or openssl?

Which HTTP framework? actix-web, axum, dropshot or hyper?

What about a time library? time, chrono or jiff (how I'm even supposed to find this one)?

You get it, if you are not constantly following the latest news, your code is already technical debt before it's even written. Fragmentation is exhausting.

I just looked at the dependencies of a medium-sized project I'm working on, and we have 5+ (!) different crpyto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto. All of this because our various dependencies have picked a different one for their own cryptographic usage. This is insane, first because it introduces a lot of supply chain attack entry points, but also because there is no way that we will audit all of them"

Source: https://kerkour.com/rust-stdx

My moderate-sized Rust web service project requires 587 third-party crates which seems ridiculous.

Fortunately, cargo makes it easy to manage the dependencies, but unfortunately I don't know how well supported or maintained the dependencies are. How well will they be maintained in five years from now? Will I need to find newer libraries and rewrite portions of my project to provide the same features that I have now? I don't know.