3 ms·

IMO it is, and usually the benefits of async Rust aren't that great for simple projects. To me the biggest annoyances is fractured nature of async libraries, yo

IMO it is, and usually the benefits of async Rust aren't that great for simple projects. To me the biggest annoyances is fractured nature of async libraries, you have to choose runtime and then the libraries. Tokio or async-std? They are working to fix it, but until some sort of "official" standard library for async exists it remains fractured... Secondly adding some parallelization in normal "vanilla" Rust with std seems rather easy with channels and Rayon, so I'm not looking to retry async rust if I don't have to.

codeflo 5y ago
The fact that the Rust project resists standardizing too early — which could lead to being stuck with a bad design — is in my opinion one of its virtues. But I agree that we’re past that point at least for simple async worker threads and simple IO. I don’t follow the progress that closely, but I think work is happening towards standardization there.
- Ciantic 5y ago
  > The fact that the Rust project resists standardizing too early — which could lead to being stuck with a bad design — is in my opinion one of its virtues. I think the same way, and was enthusiastic of async Rust at the beginning, but right now I think it has caused a mess in libraries. Maybe they did the standardization way too early? Maybe they could have waited until the async libraries can be separated from runtimes, which I think they are now planning to do. If you start to dig through otherwise useful libraries you see a divide to those who async and those who don't, and top of that which runtime they have chosen. Mixing and matching between those is painful.
pornel 5y ago
In practice there's no fragmentation problem: you use tokio, and never think about async-std again (despite the name, async-std is not standard/official in any way). Everyone supports tokio, and there isn't anything unique to async-std that doesn't have a tokio alternative. This state totally sucks for the authors of async-std who have an uphill battle getting traction in the tokio-dominated ecosystem, but from user perspective you can pretend the problem doesn't exist. Treat tokio as the standard library, as if it was hardcoded and you had no choice on the matter.

codeflo 5y ago

The fact that the Rust project resists standardizing too early — which could lead to being stuck with a bad design — is in my opinion one of its virtues. But I agree that we’re past that point at least for simple async worker threads and simple IO. I don’t follow the progress that closely, but I think work is happening towards standardization there.

Ciantic 5y ago
> The fact that the Rust project resists standardizing too early — which could lead to being stuck with a bad design — is in my opinion one of its virtues. I think the same way, and was enthusiastic of async Rust at the beginning, but right now I think it has caused a mess in libraries. Maybe they did the standardization way too early? Maybe they could have waited until the async libraries can be separated from runtimes, which I think they are now planning to do. If you start to dig through otherwise useful libraries you see a divide to those who async and those who don't, and top of that which runtime they have chosen. Mixing and matching between those is painful.

pornel 5y ago

In practice there's no fragmentation problem: you use tokio, and never think about async-std again (despite the name, async-std is not standard/official in any way). Everyone supports tokio, and there isn't anything unique to async-std that doesn't have a tokio alternative. This state totally sucks for the authors of async-std who have an uphill battle getting traction in the tokio-dominated ecosystem, but from user perspective you can pretend the problem doesn't exist. Treat tokio as the standard library, as if it was hardcoded and you had no choice on the matter.