I think those two things are orthogonal. I'm not against somebody bundling up nice Rust libraries and providing a pre-install package or providing nice GUIs around (like Borland used to do and Qt still kind of does). Or an OS providing a nice set of libraries.
However, the standard library of a systems language has a special relationship with the compiler. This is the case for C and C++ where the compiler and the standard library also has a special relationship with the platform like GNU or musl with Linux, or MSVC and Windows. It makes changing APIs or modernizing infrastructure almost impossible without creating an entire new OS and porting all compilers and standard libraries to it. Moreover the newer C++ standards actually force you to define such a relationship (with std::initializer_list and threading stuff). It is basically impossible to make an OS-agnostic C++ compiler that doesn't leak its and platform's internals to the user.
Luckily Rust mostly abstracts around the platform-compiler boundary and its standard library so the platform dependencies are implementation details. Unlike C and C++, one can write Rust without caring about how the underlying OS does ABI. However, Rust compiler and Rust std has a special relationship. `Box` can only be defined as part of Rust standard library that's compiled together with the Rust compiler itself. Its special relationship is kind of a blocker for -Zbuild-std and std-aware Cargo which prevents size-optimizing std for embedded systems. Without that magic (i.e. compiling the compiler itself, or worse bootstrapping it) you cannot independently create a `Box`.
I want this kind of library to contain as little as possible since it is convenient to define these kinds of relationships and rely on magic. Modern C++ has too much such magic. Rust is mostly on a correct path with std, core, alloc etc. separations. These kinds of boundaries make it possible to share as much code as possible with many libraries without finding hacky ways around std (which you have to do with C++).
This doesn't mean that I wouldn't appreciate more actual functional libraries maintained by Rust Foundation-funded people and be part of the project or even easily installed. However those libraries should be effortlessly exchangeable. I think current Cargo ecosystem achieves this mostly. However I would appreciate a more curated Cargo repository that contains only a limited set of really well maintained packages (similar to Maven's repos in Java world).
However, the standard library of a systems language has a special relationship with the compiler. This is the case for C and C++ where the compiler and the standard library also has a special relationship with the platform like GNU or musl with Linux, or MSVC and Windows. It makes changing APIs or modernizing infrastructure almost impossible without creating an entire new OS and porting all compilers and standard libraries to it. Moreover the newer C++ standards actually force you to define such a relationship (with std::initializer_list and threading stuff). It is basically impossible to make an OS-agnostic C++ compiler that doesn't leak its and platform's internals to the user.
Luckily Rust mostly abstracts around the platform-compiler boundary and its standard library so the platform dependencies are implementation details. Unlike C and C++, one can write Rust without caring about how the underlying OS does ABI. However, Rust compiler and Rust std has a special relationship. `Box` can only be defined as part of Rust standard library that's compiled together with the Rust compiler itself. Its special relationship is kind of a blocker for -Zbuild-std and std-aware Cargo which prevents size-optimizing std for embedded systems. Without that magic (i.e. compiling the compiler itself, or worse bootstrapping it) you cannot independently create a `Box`.
I want this kind of library to contain as little as possible since it is convenient to define these kinds of relationships and rely on magic. Modern C++ has too much such magic. Rust is mostly on a correct path with std, core, alloc etc. separations. These kinds of boundaries make it possible to share as much code as possible with many libraries without finding hacky ways around std (which you have to do with C++).
This doesn't mean that I wouldn't appreciate more actual functional libraries maintained by Rust Foundation-funded people and be part of the project or even easily installed. However those libraries should be effortlessly exchangeable. I think current Cargo ecosystem achieves this mostly. However I would appreciate a more curated Cargo repository that contains only a limited set of really well maintained packages (similar to Maven's repos in Java world).