The author's main argument that it is okay for the standard library to be small is that you can pick an optimal(for you) implementation of functionality, and you can check licenses of code easily with cargo, library authors prefer to have autonomy, and you can lock in dependencies to a specific version.
I feel like the main advantage of a large standard library is already vetted reasonable default code. When using python I don't need to read through a billion blog posts and forums to find a good json library. There is a decent one already in the standard library and it basically works. If I need a better one, then I would want to go searching. I think having a sensible default out of the box helps more than it hurts. For the compile times, why would cargo make you pay for what you don't use?
Completely agree that the standard library is a sensible default. If a new user is wading through blog posts, something has definitely gone wrong. The hope is, the new user encounters the right resources. You mentioned json. If a user searches "rust read json", the top result is the best result - serde_json. Next is stackoverflow. All 5 answers from the Google results page mention the same - serde_json. After that, 3 blog posts about the same library. Sadly, it's only after that the Rust cookbook shows up. It recommends the same library, but it feels a bit low.
Your point is valid in general though. If it's a more niche problem, finding the right library might not be obvious and users might give up.
Using the example of JSON, one of the issues in the Java ecosystem is that there are 3-5 JSON libraries(GJSON, Jackson, Org.json, Genson, etc.) that are commonly used. Today there is a clear choice for Rust, but in 5 years it will probably be more fractured.
If you have one or more dependencies that also need to parse JSON, and they choose differently, you could have cargo building multiple JSON libraries and including parts of them in your application, which would increase the bloat of the resulting binary.
This is of course a problem with any language and not Rust specific, but in an ideal world there would be one best way for doing most things included in the standard library and everyone would just use those.
What's funny is that serde pretty much dominates the serialisation space in Rust. It's as close to a de facto standard as possible. I would bet decent money that it remains the top lib in 5 years time.
But your point stands - in an ideal world it would be nice if there was one obvious way to do it, and that obvious way was in the standard library.
>> It's as close to a de facto standard as possible.
Then why not put it in the standard library?
If it is mature enough, then why not add it so anyone can use it without having to dowload it everytime? So that new users to Rust are not forced to search through all the possible candidates to find the best answer?
If it is not ready, sure wait until it is or use something better.
In the industry I work in, software needs to be mature, stable, and boring. I would love to start using Rust at work, but it is not ready in terms of maturity and stability because of reasons like these.
Rust needs a standard.
Rust needs multiple mature implementations.
Rust needs a standard library that covers enough "everyday" use cases that you don't have to download half of crates.io to accomplish everyday tasks
Perhaps it will be ready in 10 to 15 years.
Until then, we will keep building things in C and C++.
Counterpoint: maintaining an entire language is really hard and time-consuming. If you increase the surface area to a large stdlib, you're suddenly requiring core maintainers to spend a lot of time debugging libraries just to release a language version.
Also consider that PHP, which has an astonishingly huge stdlib, still has native classes that handle SOAP requests that must be maintained for backwards compatibility.
Meta note - although some older languages have the same issue of cruft in their standard libraries, I thought it's better not to mention them. I felt it's better to keep it focussed on Rust. Even though it's relatively new and has a small standard library, it has accumulated code that look like mistakes in hindsight.
> it has accumulated code that look like mistakes in hindsight.
I don't think there is any language that people use that doesn't have this issue. C++ for example has a huge number of warts. Ideally like with std::auto_ptr they are deprecated and removed over time.
Right, it's completely fine. You'd have to be an oracle to write software that never rots at all. I'm not criticising anyone who has written or signed off on adding code to any standard library that was later deprecated.
However, in hindsight it was the right call to not add some libraries to Rust's standard library. In some cases, they turned out to be dead ends (rustc_serialize) or needed a lot more time to bake (rand).
9 comments
[ 3.8 ms ] story [ 29.0 ms ] threadI feel like the main advantage of a large standard library is already vetted reasonable default code. When using python I don't need to read through a billion blog posts and forums to find a good json library. There is a decent one already in the standard library and it basically works. If I need a better one, then I would want to go searching. I think having a sensible default out of the box helps more than it hurts. For the compile times, why would cargo make you pay for what you don't use?
Your point is valid in general though. If it's a more niche problem, finding the right library might not be obvious and users might give up.
If you have one or more dependencies that also need to parse JSON, and they choose differently, you could have cargo building multiple JSON libraries and including parts of them in your application, which would increase the bloat of the resulting binary.
This is of course a problem with any language and not Rust specific, but in an ideal world there would be one best way for doing most things included in the standard library and everyone would just use those.
But your point stands - in an ideal world it would be nice if there was one obvious way to do it, and that obvious way was in the standard library.
Then why not put it in the standard library?
If it is mature enough, then why not add it so anyone can use it without having to dowload it everytime? So that new users to Rust are not forced to search through all the possible candidates to find the best answer?
If it is not ready, sure wait until it is or use something better.
In the industry I work in, software needs to be mature, stable, and boring. I would love to start using Rust at work, but it is not ready in terms of maturity and stability because of reasons like these.
Rust needs a standard.
Rust needs multiple mature implementations.
Rust needs a standard library that covers enough "everyday" use cases that you don't have to download half of crates.io to accomplish everyday tasks
Perhaps it will be ready in 10 to 15 years.
Until then, we will keep building things in C and C++.
Also consider that PHP, which has an astonishingly huge stdlib, still has native classes that handle SOAP requests that must be maintained for backwards compatibility.
I don't think there is any language that people use that doesn't have this issue. C++ for example has a huge number of warts. Ideally like with std::auto_ptr they are deprecated and removed over time.
However, in hindsight it was the right call to not add some libraries to Rust's standard library. In some cases, they turned out to be dead ends (rustc_serialize) or needed a lot more time to bake (rand).