Planning the 2021 Roadmap
blog.rust-lang.org
blog.rust-lang.org
As someone who has tried Rust but has run into issues actually using it, I want Rust to improve its standard library and stop pointing people to "de-facto" crates on official documentation. I shouldn't need a crate to get a backtrace. It doesn't make sense to use a create to figure out if a type is an integer, or to work with Rust's AST. I understand that the team does not want to commit to maintaining these, or keeping them stable, or whatever, but there are many places where "just use xyz from J. Random Developer" is not a thing that someone wants or even can do. Having something in the standard library makes it easy to depend on and trust.
Adding a library dependency takes you all of 10 seconds. Committing to supporting a standard library function that gets deprecated down the line is an endless effort.
I love that Python has a standard library that's thorough enough to do productive work with. But anyone who uses python seriously has to drop those on favor of more modern external deps, sooner rather than later, and so we're back to square one.
Now, I fully understand that when something gets added to the standard library it needs to be supported. I'm saying "Do it." Rust likes to claim that it is backwards compatible and all, and I do understand that the work that is done for this is non-trivial. But still, it's mildly annoying to hear that because there's this little voice in the back of my head that says "well yeah, because anytime something comes up that would need to be supported it just never gets added, so it ends up in a crate that is 'no longer part of Rust' when it breaks". Nobody is saying that we need to make Rust another Python (well, if there are then I would be glad to argue otherwise). But please, expand the standard library; make it possible to use the language for useful things without having to commit to 37 transitive dependencies. Maybe see if it's possible to start working with the more stable and widely accepted crates and moving them under the umbrella of the standard. That kind of thing.
I definitely get the point about the additional load to maintain a deep standard library but, as someone from a heavy Python background who has only begun to dabble in Rust, it felt a little off to have to reach for a crate just to do a regex match on a string.
What I think will help is have a "Rust Distribution" like anaconda, where that "defacto" crates are combined and more importantly, are part of the maintainments effort.
But to avoide the fate of python and others, that "Rust Distribution" is mean to exist ONLY FOR THE EDITION. When a new edition show, then another "Rust Distribution" with +/- crates is defined and that is the what is to be used. This ways, you know what to use as long you stay in the edition, and if you move, you know is to move along (and you can still use the older crates anyway)...
The only thing I can think of is an async runtime but that is both controversial and a mostly solved issue with async-std.
I say this as someone who has written extensive amounts of rust, C, and C++. The standard library is good enough, any batteries you might want to include probably fit your use cases and not mine which is why we have the crates ecosystem to begin with.
The gist of this would be:
1. It has a larger, more committed team than J. Random Developer. The core rust team promotes this as good place for Rust enthusiasts to contribute if they're not compiler specialists.
2. Everything added to the crate has similar naming conventions, argument order, intermediary structures, package hierarchy, etc. Basically an experienced user should have some chance of correctly guessing how to call a function they've never used before but hope is in the library. (The Java library does this - I just correctly guessed one of the ways to call java.awt.Graphics.drawPolygon without being sure it exists.)
3. There should only one of everything in the crate. (Java does not do this - awt vs swing for example.)
4. The extended standard library absorbs crates that are de-facto standards and no longer receiving active development / no longer need active development. It may rename some stuff on the way to fit point 2.
And some examples of crates in a current project that I thought could stand to be in such a library, either now or eventually, are dotenv, rust-crypto, serde, and env_logger.