Also, some suggested metapackages/bundles wouldn’t hurt for newbies, like a set of crates for developing command line tools, for example.
Something like this: https://marketplace.visualstudio.com/
What if a 'winner' today is a loser in a year? What if we come up with a new approach to solving a problem that requires a breaking change, or a new crate?
Would someone be inclined to try to improve the state of HTTP given a good enough version in std? Would we be ok with discouraging that sort of competitive approach?
To be honest, all I see are downsides to having a huge std lib. The benefit seems to be that there isn't an obvious, de facto choice for what crates to use. But I think that's a problem better solved by crates.io.
My impression is that many of those who are asking for Rust's stdlib to grow are also/actually asking "please make it really easy for me to use these APIs that I care about," to which I would respond "it's OK, code can be easy to reuse even if it's not in the stdlib," "try cargo," and "crates.io needs to continue improving on discoverability."
EDIT: also, hi!
I think we're likely on the same page. The desire to make writing an HTTP server that much easier by providing a quick-to-use solution is entirely reasonable.
I just don't believe the solution is some 'sanctioned', permanent addition to std.
Better to be solved in crates.io.
That way libraries can coexist, but new developers have a single doc location to go to to find really common usages.
It might be nice to have autogenerated docs about the most used soltuions, but I guess the rust cook book sort of fills that niche.