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.
Well, no, not really. You see, saying that it takes 10 seconds to add a dependency is really saying "I add dependencies by picking the first thing that shows up when I type '[problem] rust' and then I copy the example code in the README and tweak it until it does what I want", which is unfortunately how many projects are run but exactly how you set yourself up for all the problems that come with dependencies–licensing, transitive dependency bloat, quality issues, poor maintenance… The only way out of that problem is that you spend way longer auditing whatever it is that you're adding for all those things, at which point I think you'll begin to understand why I am asking for the standard library to meet my use cases more often. (And you will notice I specifically shied away from potentially controversial dependencies: no networking, no JSON, no databases…these are things that deal with information that the language implementers would know best about anyways).
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 think you and the parent comment both make great points.
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.
I have used more than 12 langs. I think rust having a small std library is best for it kind of lang, but I'm sympathetic to your view.
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)...
It would help to be concrete with your examples to highlight what you think is missing from the standard library, since most of the time I see this commentary it's something absurd like an http server.
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.
I agree with this one. I don't think it necessarily makes sense to put in the standard library, since there are people using Rust for embedded systems and such. Instead I think it'd be best to have an "extended standard library" as a single very large crate.
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.
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.