TLDR: I think that the primary benefit of async/await is that it lets us concisely express complex concurrency; any (potential) performance improvements are just a second-order effect. We should thus judge async primarily based on how it simplifies our code, not how (or if) it makes the code faster.
I’ll be honest. I’ve written async code in Rust for years and I don’t think I’ve used select at all. I tend to drop into manually implementing Future before that point. Either way, the issues related to that macro still exist, but the author seemed to call it out and link to an article about it (which doesn’t seem disingenuous at all to me).
As for cancellation, the fact that you can cancel tasks by default in Rust has come up far more for me than any issues with unintended cancellation (which I don’t remember ever coming up, honestly). What I find myself wanting in other languages (especially JS) is the ability to both control when the task starts executing (for initialization logic or to prepare the task and pass it somewhere before it starts executing) and when it stops executing (early termination, for example with debouncing). I don’t get that by default in other languages, or often even at all in JS (unless I pass an abort controller everywhere).
the issues related to that macro still exist, but the author seemed to call it out and link to an article about it (which doesn’t seem disingenuous at all to me).
That’s fair, I stand corrected and I overreacted a bit.
I stumbled on the unintended cancellation a few times, but I’m used to select! paradigm from the other languages (and not used to how differently it behaves). I suppose I just expect the examples of its usage to be explicit and actually show what it takes to make select! behave in a way that doesn’t abruptly drop your async function after only going though half of it.
I’ll be honest. I’ve written async code in Rust for years and I don’t think I’ve used select at all. I tend to drop into manually implementing
Futurebefore that point. Either way, the issues related to that macro still exist, but the author seemed to call it out and link to an article about it (which doesn’t seem disingenuous at all to me).As for cancellation, the fact that you can cancel tasks by default in Rust has come up far more for me than any issues with unintended cancellation (which I don’t remember ever coming up, honestly). What I find myself wanting in other languages (especially JS) is the ability to both control when the task starts executing (for initialization logic or to prepare the task and pass it somewhere before it starts executing) and when it stops executing (early termination, for example with debouncing). I don’t get that by default in other languages, or often even at all in JS (unless I pass an abort controller everywhere).
That’s fair, I stand corrected and I overreacted a bit.
I stumbled on the unintended cancellation a few times, but I’m used to select! paradigm from the other languages (and not used to how differently it behaves). I suppose I just expect the examples of its usage to be explicit and actually show what it takes to make select! behave in a way that doesn’t abruptly drop your async function after only going though half of it.