It still lacks basic functionality like a JSON parser, regex, directory walker, rnd generator and cli arg parsing.
I won't mention lack of date/time lib because that's complex and changes often.
That's why projects end up with 100s of crates, sometimes 1000s.
This might not be a well received fact in Rust community, but it's a fact nonetheless.
Ok, so I created an empty cargo project and added serde_json, regex, walkdir and rand. This added 28 crates, several of these from the same authors.
If the absence of these features caused 1000s of dependencies, then where are the remaining 972?
When I look at a project at work then what inflates the dependency tree is a combination of a whole webserver application stack plus SDKs consisting of dozens of crates. Those then pull in an async runtime or two, different HTTP clients, dozens of crypto crates and so on.
The crate count is a poor metric anyway since some subtree of dependencies is often provided by a single organization.
And I find it quite questionable that everything that's needed for an enterprise grade webserver stack should be part of the standard library, not even Java has that. Relatedly, cryptographers have failed to come up with a proven set of primitives, what's standard changes every few years.
My personal opinion on each of those:
JSON: there are a ton of different ways to do serialization and deserialization, each with their own tradeoffs, and serde (the most popular) is far from universally agreed upon. The same goes for JSON specifically, there are many different serialization formats with different tradeoffs.
regex: Owned by the rust-lang organization already. You get the benefits of trust (if you trust std, you trust the rust-lang organization anyway), but without the issues of being in std (backwards compatibility and bloat). The only problem I see with that is that BurntSushi is still the owner of the package and as such can still publish new versions on his own (AFAIK crates.io currently requires at least one user owner, but that's something that can be solved by improving crates.io permissions).
walkdir: It has been been postponed, due to the complexity of WalkDir, but may be added in the future. I agree this should be in std. https://web.archive.org/web/20260820171531/https://github.co...
RNG: rand is still evolving, with breaking changes half a year ago. Preferred generators tend to change over time, so I don't see those getting into std (remember, it has to be maintained forever!). I could see the interface (traits) getting into std, but I see no advantage to it: it's maintained by rust-random, but even if you wanted it to be maintained by the same authors as the Rust language (let's say you trust them more than rust-random), you could just move it back to rust-lang-nursery or rust-lang.
CLI arg parsing: not simple at all! The community's preferred solution has 70kLOC (with support for so many features), but there's also argh, pico-args, and others, each with their own tradeoffs.
> That's why projects end up with 100s of crates, sometimes 1000s.
Also because libraries are split up in many crates. For example, regex is split in 3 crates: regex, regex-syntax and regex-automata, and depends on other crates from the same author, such as aho-corasick.
All that said, there are many crates, such as algorithms like aho-corasick, that I think could me moved into the rust-lang org, like regex was.
See also: https://home.expurple.me/posts/a-big-standard-library-is-ove...