Add a new built-in but non-"std" library to add more included batteries to Rust?

TL;DR: Maybe, put some frequently missed/requested features to a new Rust::framework lib, so some batteries can be added to the language while maintain the KISS'ness of Rust::std.

Sorry for my English

Hi everybody,

I'm a Rust learner with a little bit Go & PHP background.

I had very delightful experience with those too languages. And I found the main reason of that is because they both have very large build-in batteries which allowing me do almost everything more easier.

When I turn towards the Rust, I found myself jumping in to a language which been settled up on a different principle that believes Small is better.

Of course I understand the KISS principle, so I also understand why Rust choose to do that. However (Yeah, here we go), no one can deny the benefit of some powerful batteries.

It's just like candy. As a adult, I'll not be sad because of lack of candy, but I could be happy if I can have some.

After reading few articles and conference talks, I realized that may be the KISS and More Batteries conflict can be resolved by .... well, introduce a new name.

Currently Rust have Rust::std which dedicated for providing fundamental language functions, so it has to be small and simple. And because of that, something like Green Threads, Coroutine etc is not suitable for Rust::std.

But if there is another build-in library called ... let's say Rust::framework (I made up this name so I can made my point), then, suddenly Green Threads and Coroutine have a new place to go rather than been removed completely.

So the different between Rust::std and Rust::framework:

• Rust::std still the fundamental lib, so only fundamental stuffs can be included.
• Rust::framework is the sweet sugars which provides some advanced functions for you to choose which will let you use this language more easier in practice.

END OF MAIN TOPIC

"Then, why not just use crates?" you may ask. Well yes, there are many crates out there of course, but out-sourcing some frequently used features to an external dependence may not always be good in the real world.

As you add a new external dependence to your project, you also take some risk: The dependence may contains bug that can't be fixed in time, it's API may frequently changing between versions (No project management), or it will be/already been abandoned. No need to say you also need to learn how to use that dependence, and find way to properly introduce it to your existing system.

With a built-in library, those problem could be all reduced as we can believe all build-in libraries are done by Rust Pros who made Rust and been reviewed frequently by Rust community.

Thank you for reading.

The issue names no files, tests, or implementation entry points. Start by reviewing the proposal's rationale and the repository's RFC process, then determine whether the built-in library concept has a concrete, scoped design. Done would require an explicit decision or an accepted RFC with defined scope and motivation.