> They're all individually great pieces of software but none of them feel complete and I always reach out for something that is not there.
I'm not convinced that the libs being in std would help you with this issue. Instead you'd probably have the same incompleteness with a whole bunch of the functionality only available in nightly rust because of the stability contract implied by std.
Picking either tokio or async-std (flip a coin if you can't decide) and using their recommended way doing a given async task isn't really all that different from doing the same with a hypothetical std::async.
Is there any work on creating feature-based sub-standard libraries that are aggregations of popular (and robust) crates but tying all of their versions together?
For example, I'd like to put in my Cargo.toml:
sstd = { version = "1.0", features = ["clap", "serde", "rand"] }
Where the sstd crate essentially has a whole mess of crates bundled together ensuring only one version is used for each individual dependency?
Perhaps this is a question best asked elsewhere - your comment just brought it once again to my mind.
Where I get some analysis paralysis is in getting one library over another one.
Eg. I'd love to have a std lib recommended way of doing async and task execution with a thread pool eg. Async-std vs Tokyo Vs Rayon.
They're all individually great pieces of software but none of them feel complete and I always reach out for something that is not there.
To be fair I don't think this is rust specific, I think this is just the bane of OSS solutions with unpaid maintainers.
Sure, I could contribute something or fork them but it takes time.
I'd prefer to just buy in into a solution, pay a monthly fee and know that I'll get a full featured solution with a well paid maintainer.