What do you think about the points the authors makes?
You must log in or register to comment.
It’s not clear to me what the author considers “questionable choices” for Rust.
The only point I found that falls under “questionable choices” is :
“If you go looking for compression support in Rust, there’s none in the standard library. But you may notice the flate2-rs repo under the official rust-lang GitHub namespace. If you look at its transitive dependencies: flate2-rs depends on (an individual’s) miniz_oxide which depends on (an individual’s) adler that hasn’t been updated in 4 years. 300 lines of code including tests. Why not vendor this code? It’s the habits a small standard library builds that seem to encourage everyone not to.”
“Even official packages may end up depending on external party packages, because the commitment to a small standard library meant omitting stuff like compression, checksums, and common OS paths.”Which is somewhat valid, but imo it’s really not as big of a deal breaker as they’re trying to make it out to be.
It would be as interesting to annotate blocks in JavaScript or Python as must-not-allocate too.
I don’t really understand why this is desired. I work with both for my day job, and I’ve never cared whether a function allocates and certainly not how one allocates (unless I’m using something like numpy arrays). As interpreted languages with runtime type enforcement, the concept of “allocation” gets a bit fuzzy, and it makes sense to assume all objects live on the heap, including basic types (e.g. in Python, an int is an object that takes up 28 bytes), and anything else is a nice optimization.
If I care about whether something allocates in JavaScript or Python, I’m using the wrong language and should probably drop to a native-extension or WASM.
That’s a pretty minor nitpick though.
As for large standard libraries, I do think Rust should have a bigger standard library, but not nearly as big as Go. I’ve seen people rally around Go’s standard library as “the right way,” even if it doesn’t fit well for some reason.
For example, I was working on a JSON API and wanted a simple extension to the library to allow marking fields of a struct read- or write- only so I could, for example, accept passwords coming in and hide them going out (e.g. in case the object gets logged or something), but the maintainers didn’t want that. They have “omitempty” and “-” (ignore), and they said they would prefer to not even have that. So I used a workaround: every time I load data, I move the password to a different variable and clear that one. That’s really gross for something many (most?) JSON libraries that have metadata support.
I could just use a third party JSON library that supports that feature, but since the current one is close enough, I’m more likely to just hack around it.
So I think the author is overemphasizing the benefits of a large standard library. A small one forces you to decide what library you use, at which point you look at tradeoffs, whereas a standard library raises the bar for looking at other libraries.
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 aflate3, 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:
- 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).
I like the approach Jetbrains has taken with extension libs to add functionality that could’ve been in a bloated standard library.
A bit tangential, but if the US government really commits to pushing big tech firms to migrate to memory safe languages, where would that leave Zig?
It seems completely implausible to rewrite all the deployed C and C++ in the world any time soon. Even so, the uncertainty created by a top-down push might be enough to stall adoption of an unsafe language.
I just wondered if anyone knows whether that story has affected the plans of the Zig maintainers at all. Or whether there has been any spike in Rust job postings?
It’s mostly a good article. Do you have particular questions?
Zig has a good standard library
Is this the language that doesn’t define strings in the standard library? Or is that nim?
Please consider not adding licences.
