News for hackers. Stuff that matters.
Re:A four year plan for async Rust by capableweb on Tuesday November 07, 2023 @12:54PM (#38180283)
I'm not sure "percentage of usage" is a metric you can use to fully decide how "useful" something is. Take macros in Clojure for example, usually you just have a few of those, but the ones you have are really useful, they give a lot of functionality and practicality to the language. Maybe the same thing is happening with sync/async generators?
Re:A four year plan for async Rust by munificent on Tuesday November 07, 2023 @01:21PM (#38180696)
That's a good observation about a lot of language features, yes. Macros are a particularly good example.

But for a feature like generators which is, I think, essentially user-facing syntactic sugar, I do think a count of usages is a pretty good measure of usefulness.

It's probably also worth noting that my data here is from published packages, which tends to skew towards reusable libraries and away from application code. So, if anything, I would expect this to be an over-count of their use if they primarily made libraries/frameworks useful on behalf of application developers.

Re:A four year plan for async Rust by steveklabnik on Tuesday November 07, 2023 @01:30PM (#38180817)
> I think, essentially user-facing syntactic sugar,

One thing to remember is that Rust is a bit weird here; often times, features like this are "sugar" in a sense, but that sugar lets you write safe code, whereas the non-sugar version would force you to write unsafe. This means this kind of thing is a larger win in Rust than it would be in other languages.

Re:A four year plan for async Rust by munificent on Tuesday November 07, 2023 @01:45PM (#38181024)
Yeah, that's a good point.
Re:A four year plan for async Rust by insanitybit on Tuesday November 07, 2023 @12:58PM (#38180359)
Macros are a really good example. A world without the equivalent of `#[derive(Serialize, Deserialize)]` would suck, but it's just a few characters and I almost never write macros personally.