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