3 ms·

>I almost kind of wish Rust would just drop async, as the rest of Rust is much better, having only minor issues that are very much fixable IMO. Instead the ecos

>I almost kind of wish Rust would just drop async, as the rest of Rust is much better, having only minor issues that are very much fixable IMO. Instead the ecosystem is accelerating into it, and now it’s hard to avoid for some use cases. I've written a decent-sized project backed by Tokio/async Rust and when I'm in pure async code, it's honestly fine and I have few complaints (just... gimme stable trait async fns). I don't think it's worth dropping; async Rust has its place and is continuing to be iterated on. What needs to happen is what's happening right now: people who write in Rust need to be louder about the fact that crates should be sync first, async second. And/or (my personal irrational opinion) the language needs to get over it and adopt Tokio into Rust proper. If this proves difficult - the ability to be sync/async via feature flags - then this is something that the language needs to solve before other features IMO (I will admit I'm saying this without checking to see if it's being worked on, though).

jhugo 4y ago
It's usually easier to write the async version first and then write a sync wrapper. See for example the `postgres` crate.
- Klonoar 4y ago
  Right, I get that. I'm saying that the sync version shouldn't be "run tokio blocking in the background", because while you might be giving them an out on async infection in theory, you're still making them bring in the entire dependency tree and you're still creating more background resources than is necessary.
  - jhugo 4y ago
    The `postgres` crate launches a "current thread" tokio runtime which doesn't really have much overhead in terms of background resources. I agree about dependencies though. "async infection" is kinda interesting when you think about it. To use `postgres` as an example, talking to a database is asynchronous whether you like it or not. To use blocking APIs to access it is just to allow something (typically the OS) to pretend that it isn't. In general I've found the experience of writing a program async from the beginning to be very good in Rust, and in the very rare cases (in my field of work) where I have some genuine blocking to do, Tokio provides good tools for that (`tokio::task::spawn_blocking` and `tokio::task::block_in_place`). I can imagine that if you were writing a largely CPU-bound program, async would feel more like an "infection".

jhugo 4y ago

It's usually easier to write the async version first and then write a sync wrapper. See for example the `postgres` crate.

Klonoar 4y ago
Right, I get that. I'm saying that the sync version shouldn't be "run tokio blocking in the background", because while you might be giving them an out on async infection in theory, you're still making them bring in the entire dependency tree and you're still creating more background resources than is necessary.
- jhugo 4y ago
  The `postgres` crate launches a "current thread" tokio runtime which doesn't really have much overhead in terms of background resources. I agree about dependencies though. "async infection" is kinda interesting when you think about it. To use `postgres` as an example, talking to a database is asynchronous whether you like it or not. To use blocking APIs to access it is just to allow something (typically the OS) to pretend that it isn't. In general I've found the experience of writing a program async from the beginning to be very good in Rust, and in the very rare cases (in my field of work) where I have some genuine blocking to do, Tokio provides good tools for that (`tokio::task::spawn_blocking` and `tokio::task::block_in_place`). I can imagine that if you were writing a largely CPU-bound program, async would feel more like an "infection".