> After two decades of JavaScript and decent experience with Go, this is the most significant source of frustration and friction with Rust. It’s not an insurmountable problem, but you must always be ready to deal with the async monster when it rears its head. In other languages, async is almost invisible.

I am a former C and C++ programmer who lived calling into pthread almost every week for a decade. I use async rust everywhere now.

I don’t get the hate that async gets. In my opinion, everyone should be using async for everything. Including stuff that’s seemingly single threaded “simple” stuff.

Recently tried writing some async Rust to compare the error handling when nested async calls are made to how errors are handled in Go, and it seemed like the trivial example I was trying to write up simply couldn't be done without involving Tokio. That barrier simply doesn't exist in Go, or C#, or Typescript.

For instance, you apparently cannot `await` in the main function without a decorator you import from, you guessed it: Tokio.

Why are you trying to avoid Tokio lol, tokio is the defacto async runtime in rust, saying you're trying to avoid it is like saying you're trying to avoid async while writing async, somehow people act like if they merged tokio into std and instead of #[tokio::main] or whatever you had to do #[async::main] it would somehow be better.

Once you stop fighting the fact that tokio = async rust for 99% of cases, things are quite smooth.

If Tokio was the final answer, https://github.com/tokio-rs/tokio-uring/ wouldn't exist.