3 ms·

I think the better way to think about async Rust is to use it when it's beneficial to developer productivity and to avoid it when not. There are quite a few si

I think the better way to think about async Rust is to use it when it's beneficial to developer productivity and to avoid it when not. There are quite a few situations where it makes the code easier compared to alternatives you could come up with. I don't think for a second that async Rust should be picked for performance reasons. You get a feeling for what is a good use of async and bad use of async relatively easily these days as the ecosystem is maturing.

baq 3y ago
What arguments are there for async if not performance? Threads/fibers/gofuncs/actors/... are easier to reason about. Async is super helpful to avoid overhead of thousands of threads, but makes just about everything else harder.
- bryanlarsen 3y ago
  I disagree. I've got several programs with a async select based main loop and others with threads, and the former are easier to reason about in my opinion. Threads hide effects. However, Tokio tries to be the best of both threads and async and sometimes ends up being the worst of both when Sync/Send/etc creep into function signatures.
- the_mitsuhiko 3y ago
  Async makes awaiting things much easier than other primitives in the language. So for instance if you both need to wait for stuff to happen on a socket or some event happening, async select makes that super easy. You can also keep async relatively local to a function that does these things and is itself blocking otherwise.
  - amelius 3y ago
    Yes, async is easier, but granularity of performance is a real downside. The CPU is a resource too, and needs to be managed more carefully than async can do. There's a reason why people stopped using cooperative multitasking like in Windows 3.1 ...
    - the_mitsuhiko 3y ago
      Sure, but that’s not really an argument for or against async but for or against different runtime policies.
      - amelius 3y ago
        What good are "runtime policies" if you're in a single thread that you can't interrupt (which is what async is)?
        the_mitsuhiko 3y ago
        Async is not really that in Rust. While it's true that a singular poll cannot be preempted, things like task::spawn schedule that on a multi threaded executor. So a lot of cases behave just like threads except you await them from somewhere else.
- sshine 3y ago
  I use (custom-made) actors and (Tokio) channels a lot, and I build them with async. I do make separate threads when necessary (e.g. to encapsulate blocking I/O). It can approximate an Erlang experience. But with a lot more boilerplate and lack of good actor library patterns.
amelius 3y ago
> I think the better way to think about async Rust is to use it when it's beneficial to developer productivity and to avoid it when not. How do you know if what is best doesn't change as the project you're working on progresses and your manager tosses in new requirements? I'd say better pick a technique (or even language) that works all the time.
- seanhunter 3y ago
  There isn’t one technique that works all the time. Life is unfortunately about tradeoffs whenever you do something complex.
  - amelius 3y ago
    So choose a technique and language that least limits your design freedom. Choosing performance as your #1 priority is often a bad idea as it gets you into a straight-jacket from the start, making everything else much more difficult and slows down development to a crawl. Unless you're developing an OS kernel perhaps. Computers are fast enough these days, let them do part of the work for you! And you can always write a faster version of your software when there is a demand for it.
    - sshine 3y ago
      > Choosing performance as your #1 priority is often a bad idea You can write inefficient code and optimize it later. > it gets you into a straight-jacket from the start, making everything else much more difficult and slows down development time to a crawl. Unless you're developing an OS kernel perhaps The argument seems to break down: Surely you don't want to be in a strait-jacket if you're developing an OS kernel. Somehow Rust is equated with always being in a strait jacket. The cost of writing highly concurrent programs is pretty much the same in every language except ones that have concurrency at the core (Erlang). I don't see much difference between starting with Java or Rust in terms of avoiding complexity caused by having to build things that a concurrent runtime could give to you for free.
      - 3y ago
zaphar 3y ago
It is increasingly harder to avoid async Rust if you do any form of IO. Most of the useful io based crates assume you are doing async with a very minor amount of them giving you a non async api. Out of the ones that do they are bundling an executor to power that api because they don't want to implement it twice. I think part of what is feeding this sort of backlash against it is the way that it creates two different rust ecosystems. One of them, the non async version, being decidedly a second class citizen.
- bryanlarsen 3y ago
  It looks like there's good movement on the proposal to bring pollster[1] or similar into the Rust standard library. I think that's awesome. They've been afraid to "bless" an executor for good reasons, but pollster has 0 chance of "winning" even if blessed since it lacks so many features. However it's a solution to the problem you expressed: I/O crates can be async and used with pollster in sync contexts. 1: https://docs.rs/pollster/latest/pollster/ https://docs.rs/pollster/latest/pollster/
  - Aissen 3y ago
    I haven't been following, would you have a link to this proposal ? A quick search of pollster in rust-lang/rust and rust-lang/rfcs does not bring any interesting result.
    - bryanlarsen 3y ago
      Good question. I might have been projecting my hopes to make it sound more formal, but the only thing I could find following my cookie crumbs was the mention in https://without.boats/blog/why-async-rust/ https://without.boats/blog/why-async-rust/

baq 3y ago

What arguments are there for async if not performance? Threads/fibers/gofuncs/actors/... are easier to reason about. Async is super helpful to avoid overhead of thousands of threads, but makes just about everything else harder.

bryanlarsen 3y ago
I disagree. I've got several programs with a async select based main loop and others with threads, and the former are easier to reason about in my opinion. Threads hide effects. However, Tokio tries to be the best of both threads and async and sometimes ends up being the worst of both when Sync/Send/etc creep into function signatures.
the_mitsuhiko 3y ago
Async makes awaiting things much easier than other primitives in the language. So for instance if you both need to wait for stuff to happen on a socket or some event happening, async select makes that super easy. You can also keep async relatively local to a function that does these things and is itself blocking otherwise.
- amelius 3y ago
  Yes, async is easier, but granularity of performance is a real downside. The CPU is a resource too, and needs to be managed more carefully than async can do. There's a reason why people stopped using cooperative multitasking like in Windows 3.1 ...
  - the_mitsuhiko 3y ago
    Sure, but that’s not really an argument for or against async but for or against different runtime policies.
    - amelius 3y ago
      What good are "runtime policies" if you're in a single thread that you can't interrupt (which is what async is)?
      - the_mitsuhiko 3y ago
        Async is not really that in Rust. While it's true that a singular poll cannot be preempted, things like task::spawn schedule that on a multi threaded executor. So a lot of cases behave just like threads except you await them from somewhere else.
sshine 3y ago
I use (custom-made) actors and (Tokio) channels a lot, and I build them with async. I do make separate threads when necessary (e.g. to encapsulate blocking I/O). It can approximate an Erlang experience. But with a lot more boilerplate and lack of good actor library patterns.

amelius 3y ago

> I think the better way to think about async Rust is to use it when it's beneficial to developer productivity and to avoid it when not. How do you know if what is best doesn't change as the project you're working on progresses and your manager tosses in new requirements? I'd say better pick a technique (or even language) that works all the time.

seanhunter 3y ago
There isn’t one technique that works all the time. Life is unfortunately about tradeoffs whenever you do something complex.
- amelius 3y ago
  So choose a technique and language that least limits your design freedom. Choosing performance as your #1 priority is often a bad idea as it gets you into a straight-jacket from the start, making everything else much more difficult and slows down development to a crawl. Unless you're developing an OS kernel perhaps. Computers are fast enough these days, let them do part of the work for you! And you can always write a faster version of your software when there is a demand for it.
  - sshine 3y ago
    > Choosing performance as your #1 priority is often a bad idea You can write inefficient code and optimize it later. > it gets you into a straight-jacket from the start, making everything else much more difficult and slows down development time to a crawl. Unless you're developing an OS kernel perhaps The argument seems to break down: Surely you don't want to be in a strait-jacket if you're developing an OS kernel. Somehow Rust is equated with always being in a strait jacket. The cost of writing highly concurrent programs is pretty much the same in every language except ones that have concurrency at the core (Erlang). I don't see much difference between starting with Java or Rust in terms of avoiding complexity caused by having to build things that a concurrent runtime could give to you for free.
    - 3y ago

zaphar 3y ago

It is increasingly harder to avoid async Rust if you do any form of IO. Most of the useful io based crates assume you are doing async with a very minor amount of them giving you a non async api. Out of the ones that do they are bundling an executor to power that api because they don't want to implement it twice. I think part of what is feeding this sort of backlash against it is the way that it creates two different rust ecosystems. One of them, the non async version, being decidedly a second class citizen.

bryanlarsen 3y ago
It looks like there's good movement on the proposal to bring pollster[1] or similar into the Rust standard library. I think that's awesome. They've been afraid to "bless" an executor for good reasons, but pollster has 0 chance of "winning" even if blessed since it lacks so many features. However it's a solution to the problem you expressed: I/O crates can be async and used with pollster in sync contexts. 1: https://docs.rs/pollster/latest/pollster/ https://docs.rs/pollster/latest/pollster/
- Aissen 3y ago
  I haven't been following, would you have a link to this proposal ? A quick search of pollster in rust-lang/rust and rust-lang/rfcs does not bring any interesting result.
  - bryanlarsen 3y ago
    Good question. I might have been projecting my hopes to make it sound more formal, but the only thing I could find following my cookie crumbs was the mention in https://without.boats/blog/why-async-rust/ https://without.boats/blog/why-async-rust/