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.
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.
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.
