Async Rust is about concurrency, not (just) performance
kobzol.github.io
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.

This article very much conveys what I think.

  • farcaller@fstab.sh
    1·
    3 hours ago

    What I find slightly dishonest is bits like

    This way of using select in a loop could potentially cause issues regarding cancellation of futures (although in this case it’s fine)

    The select example is pretty straightforward and comparable to such in other languages, even to Go’s switching on channels. But rust hides an extra bit of complexity with the cancellation concerns that people don’t want to talk about unless absolutely necessary, and it is necessary in so many cases!

    • TehPers@beehaw.orgEnglish
      1·
      3 hours ago

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

      • farcaller@fstab.sh
        1·
        2 hours ago

        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.

  • esa@discuss.tchncs.de
    2·
    18 hours ago

    There also are some stories from js devs about how async/await reduced the spaghetti factor of their code a lot. So yeah, similar stories all around I think, even though async/await obviously isn’t a magical thing with no downsides