Zig, Rust and other languages

It's not clear to me what the author considers "questionable choices" for Rust.

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.

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?

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.

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?

CC BY-NC-SA 4.0