IMHO the biggest advantage of a small stdlib is that breaking changes become possible in those extracted libraries. If flate2 needs to change its API for whatever reason, it can release a 2.0.
Or I guess, there can be a flate3, too.
In particular, it also becomes possible for the whole ecosystem to slowly move over to a different library, as for example happened with failure to anyhow.
If it’s part of the stdlib instead, you can only do breaking changes by giving new names to function or whole modules, which will stick around forever and confuse noobies.
For example, want to copy a file in Python? Well, here’s a helpful spreadsheet for all the different ways you can do that: https://stackoverflow.com/a/30359308
I mean, it’s not all black-and-white. Rust has the contrary problem that the recommended library can be difficult to find out for noobies. And we may very well end up in a situation like JS, where you open a StackOverflow post and you have to look for more recent responses, because early answers are just woefully out of date.
This is kind good reason to have optional namespaces in Cargo. The Rust team could have a “rust/” prefix or something with things that are considered to be a “standard library extension,” but supports versioning and all that. Some notes about that namespace:
never imports libraries outside its namespace
releases align with Rust releases where relevant
all new stdlib packages go through this namespace first
releases follow the same standards as a change to the standard library (semver for breaking changes instead of editions, maintenance of old major versions according to stdlib policy)
This solves most of the problems a large standard library is intended to solve, while avoiding most of the downsides. Users only need to look in one namespace for “official” packages, so it’s similar to looking at the standard library (official Rust docs could even include them).
IMHO the biggest advantage of a small stdlib is that breaking changes become possible in those extracted libraries. If
flate2needs to change its API for whatever reason, it can release a 2.0.Or I guess, there can be a
flate3, too.In particular, it also becomes possible for the whole ecosystem to slowly move over to a different library, as for example happened with
failuretoanyhow.If it’s part of the stdlib instead, you can only do breaking changes by giving new names to function or whole modules, which will stick around forever and confuse noobies.
For example, want to copy a file in Python? Well, here’s a helpful spreadsheet for all the different ways you can do that: https://stackoverflow.com/a/30359308
I mean, it’s not all black-and-white. Rust has the contrary problem that the recommended library can be difficult to find out for noobies. And we may very well end up in a situation like JS, where you open a StackOverflow post and you have to look for more recent responses, because early answers are just woefully out of date.
This is kind good reason to have optional namespaces in Cargo. The Rust team could have a “rust/” prefix or something with things that are considered to be a “standard library extension,” but supports versioning and all that. Some notes about that namespace:
This solves most of the problems a large standard library is intended to solve, while avoiding most of the downsides. Users only need to look in one namespace for “official” packages, so it’s similar to looking at the standard library (official Rust docs could even include them).
I like the approach Jetbrains has taken with extension libs to add functionality that could’ve been in a bloated standard library.