The quest for usable rust libraries

I've seen few discussions recently related to rust ecosystem maturity and I'd like to express my opinion - particularly because other programming languages are often mentioned, and I am old enough to remember how and why they were created the way they are, and what costs and benefits it brings. One thing I want reader to get out of this article is that just gathering collection of recommended crates somewhere really doesn't solve all important problems.

Here is what I would like to see rust have:

1. Confidence that it covers large amount of common needs.
2. Libraries that are well supported and actively maintained for reasonable amount of time
3. Easily discoverable ways to do what I need.
4. Good documentation.
5. Coordinated release schedule I can keep up with.
6. High confidence that two crates I'll use will work nicely together and don't reinvent its own wheels.
7. Have minimal amount of ways to do things, so that I don't have to relearn everything when I'm switching projects or introducing new crates.

And I believe usable std lib (or some alternative way of achieving it) is vital for achieving those goals.

Here are some problems that rust users encounter right now:

1. Std lib is absolutely minimal, with no intention of changing that. Yet it is the first (and initially only one known) place to look at. It doesn't point new users to any other place - if you won't find what you want in there, you may be stuck.
2. Crates.io dumps anything that matches keywords (often poorly, like in case of csv) without any indication of quality beyond download count. This means time wasted on figuring out what to use and how reliable would that choice be. Even crates created and supported by core rust developers are not marked in way.
3. Every crate I am using has its own release schedule. Many of them do very poor job describing changes between versions or update process.
4. Every crate I am using has slightly different approach to documentation. Some are topic-focused, some are modeled after crate content. Some have examples, some don't. Naming conventions vary.
5. I have no idea where to look for security vulnerabilities. Each crate has its own policy on how to handle that (if at all).
6. As a result, ecosystem fragmentation is significant. There are numerous incompatible ways to do almost everything: connecting to a database, doing async io, parsing csv and so on.
   Some of those ways are better than other, some are even generally agreed as the semi-official way to go, but even then visibility of that is barely existent for people who don't live and breath rust everyday. Chance that two projects will choose the same way are slim.
   Integrating libfoo and libbar in the same project may be painful or impossible.
   Joining another existing rust project us unnecessarily hard as well, as it requires relearning new tools just because its authors made different choices.
7. New rust users will have to spend a lot of time discovering those problems and solutions.
8. Maintainers of existing apps will have hard time updating their dependencies. I'd rather have this burden on stdlib authors who can do it once a year or so, and provide nice release notes, making life of everyone else easier.

Now here are some of proposed solutions:

• Awesome rust project with curated list of crates. This is useful (and I'd love to see it being chapter of rust book).
• Stdx repo with another (very small) curated list of crates.
• RFC 1242 describes process of gradually adopting selected crates for being officially supported by rust. So far only few crates were lucky enough to follow this path.

What they have in common however, is that they do not solve much beyond discoverability. Knowing that libfoo and libbar are the best choices in their domains does not guarantee that they work together, does not make their documentation better or more unified, does not guarantee that they work at all (on my platform or with particular rust version), that they will receive bugfixes in near feature and does not sync their releases. It does help a lot, but still leaves large amount of issues untouched.

Rust ecosystem - like any other - will benefit greatly from a guidance, and suffer without it. Insanity created by many languages who don't have it is what's pushing people towards rust, we should strive to retain them and make them happy with their choice, not fighting with to much of it.

For this reason I like the idea of rust platform (proposed here: https://internals.rust-lang.org/t/proposal-the-rust-platform/3745). I'd love to see it implemented in one form or another.

By the way - since a lot of people compare rust with python - few words about it.
Please keep in mind that python was created 25 years ago - that is before internet was as popular as it is now, and that it is a runtime platform. Those reasons combined forced many things to be present in python stdlib that would not makes sense to add now in the context of rust - and python too.