The Rust stdlib is specifically intended to be as lightweight as possible (while still providing those idiomatic abstractions that might be needed throughout the ecosystem, e.g. std.future) in order to avoid the Python "dead batteries" problem.

What the Rust ecosystem is still lacking is a quasi-standard "Rust Platform" of best-practice library components where the community can freely deprecate something when a clearly better replacement comes along. There are a few "community" websites that try to provide guidance wrt. some parts of the Rust ecosystem, but nothing that feels even close to official or consensus-driven.

When I search for the Python dead batteries problem, the main issue is that the Rust developers don't want to maintain a growing list of libraries forever, especially that some of them will be depreciated over time.

This is totally understandable position, but it is still important to have sensible defaults for common tasks for end users.

One example that I can point to is Haskell, which I tried to learn from Haskell books, and it took me years to realize that it's not the language that's extremely inefficient, but the default libraries that use lists instead of arrays for most of the tasks.

I'm writing about Rayon because I see it as a reoccuring discoverability problem for people who are new to Rust.

There are many possible solutions, but one would be to have a default list of dependencies created in Cargo.toml that can of course be modified by the Rust users. Also that list can of course be changed over time by Rust developers.

Rust needs something like Rust dev blessed "extension packs", in my opinion.

Sort of like VS Code has extension packs.

Basically have some metapackages for common development areas, that pull in community vetted, high quality libraries for certain areas.

We have tried to suggest this, but the community has overwhelmingly rejected it, both as an explicit plan, and when people provided such a thing.

That's unfortunate. Whenever I talk about rust with my coworkers, getting crates through IT comes up as a major deal breaker. I imagine cooperate approved "packs" would make it much easier for us rust hobbyists to get some projects started at work in rust.

See python: my workplace (and I'm sure many others) is stuck with what's in anaconda for better or worse. The situation is certainly better than pure std.

why do they need to be dev blessed? You could do something like conda that's basically a distribution.

In my opionion the stdlib is a bit too conservative.

It is easy to end up with 200+ dependencies on more complex projects.

Some things should definitely be moved into std over the long term.

BUT: the time is not now. The language is still evolving rapidly. Upcoming features like specialization and a form of higher kinded types have the potential to impact API design a lot. I also really want named function arguments.

No-one wants to end up with a outdated and arcane standard library.

The main problem is that you cannot version the standard library (well, there are "editions" but that's a bit of a workaround for other language changes).

Go has the exact same problem, and has also historically made similar mistakes to Rust in their stdlib (the "syscall" module is strongly recommended against -- instead you should use "golang.org/x/sys"). And it should be noted that Go is even more bare-bones than Rust -- the lack of generics means you have to use "containers" which is very limited (I also have a feeling it's used by effectively nobody, because of the bad ergonomics).

I think the best solution for this problem might be some form of "meta-crate" concept which would allow you to pull in all of the well-vetted and stable libraries that most people want, without having to curate ~20 libraries yourself.

> And it should be noted that Go is even more bare-bones than Rust

In certain ways Go is more bare bones, but Go also comes with common hashes, some crypto primitives, encodings like JSON, compression/archives, logging, date/time utilities, Regex, a templating engine, an http client and server, regex, .... All of which requires a dependency with Rust.

I do remember an effort of a meta package like you mentioned. I think it was driven by brson and on Github, but I can't find it now, and it was abandoned anyway.

The problem is that several of those standard library components are no longer recommended for general usage:

* As with "syscall", users are strongly suggested to use "golang.org/x/crypto" for crypto primitives like AEAD. All of the crypto bits in the standard library are probably still "okay" but there are better interfaces and more efficient implementations in "golang.org/x/crypto".

* The "flags" package is basically useless for large projects (everyone uses "cobra" or "spf13/cli" to create CLI interfaces now). It also has the really weird Go-ism of "-flag" arguments.

* For logging, most people use "logrus" or similar. "log" isn't necessarily bad, but it's not full-featured enough that most people end up not using it.

* As for HTTP servers, at the very least you'll use "gorilla" to deal with routes -- if not completely switch to a different HTTP server implementation.

* Not to mention some of the other weird bits and bobs which are useful, but are strange to include in such a small stdlib, like "mime". Or some of the more fruity stuff like "database".

This is the downside of the batteries-included model. Especially when a lot of the bits in the Go stdlib were included early in the language's life and then quickly became a clearly bad idea but it was too late to remove them.

I agree and I'm not advocating for Rust's std to gain things like http clients or template engines.

But some parts of the ecosystem end up in a lot of projects. Conservatively extending std would be good for the language, IMO. To set a standard, reduce compile times, and ease the burden for companies that have hard review requirements for each dependency.

Some things I'd like to see in std in a few years:

* `serde`

* `rand`

* `log`, but probably without a backend, or a simple default

* a subset of `chrono`

* some parts of `rayon`

I think we could strike a balance. Don't put this stuff in the standard library, but have a category for crates that are officially blessed (or even maintained by) the core team, such that if you trust the Rust stdlib then you should be comfortable trusting these crates. Then provide binary distributions for the built crates for all tier 1 platforms at least (ideally for any platform where a binary distribution of the stdlib is available) and teach cargo how to download those. This way we maintain the ability to version these crates and have breaking changes, but without the overhead of having to recompile these crates.

What about a set of "blessed" crates (that can only depend on other "blessed" crates) that are maintained by the language developers? Seems like the best of both worlds to me.

Ah, I found the meta approach I mentioned: https://github.com/brson/stdx

There was also https://aturon.github.io/blog/2016/07/27/rust-platform/

Both failed to gain any traction.

To be clear here, yes, editions cannot change the standard library, as it must be the same across all editions.

If Rayon were in the standard library, we would never be able to make breaking changes, whereas in a crate we can possibly release a Rayon 2.0. For instance, we might want to make some low-level changes in the way iterators split their workload, per current experiments in rayon-adaptive: https://github.com/rayon-rs/rayon/issues/616

As somebody else wrote, what's really important is to stabilize a high level parallel iterator API that would probably be common even between Rayon 1 and 2. Of course I see some new APIs, like setting the task splitting policy, but some things, like parallel iteration over a vector and mapping through it should still work.

Java had to change the collection API when it added generics, but it showed that it's possible to split the API contract while improving on the underlying implementation over time. The low level Rayon primitives of course shouldn't be in the standard library name space.