[pointlessone]

> 3. You don't need to use async Rust.

Technically correct, but… Want to build a web app, every more or less popular framework is async. Want to make a web request? High change of async. Database? Very likely async, too. A huge fraction of crates are async. Right now crates.io says there are "54172 reverse dependencies of tokio”. And the page that lists them struggles mightily to load. And that’s only direct dependencies of tokio, no indirect ones, no dependencies on other runtimes, no generic dependents.

[bryanlarsen]

And all the popular ones include a synchronous interface you can use instead of the async one. If if they don't, you can wrap your calls in spawn_blocking.

You might complain about it pulling in tokio, but that's a very different complaint than having to learn/use async.

[simon_void]

Is the inclusion of synchronous interfaces a new thing? When I learned actix_web 2-3 years ago for some webservices at work, the documentation surely (at least) started of with async functions everywhere. Did that change? Were synchronous interfaces introduced later in the actix_web documentation? Or did everybody switch over to axum in the meantime and axum has synchrounous interfaces!? (I just checked and according to crates.io axum seems to have 8x the recent downloads of actix_web.) background: actix_web is still the only Rust webframework I have experience with

[saghm]

You seem to have picked the framework where the selling point is literally providing an async actor model, so yes, it's probably going to be async. If you don't like async, you probably should be spending time getting experience with one of the frameworks that's less opinionated.

[danhau]

Dependencies having to pull in tokio is an even larger issue, indicating that async‘s promise of „bring your own runtime“ is a bit of a lie. Lovely, lovely dependency hell.

[andriy_koval]

> Want to build a web app, every more or less popular framework is async.

I think its the same as Java, Tomcat has some async threadpool inside, they just hide it from you, and your favorite rust framework doesn't, you need manually move your sync logic to Tokio spawn_blocking

[traderj0e]

Java is different. Tomcat's thread pool is the older way. A lot of newer stuff was using something promises-related instead with an event loop. But then recently Java added virtual threads which should obviate the need for that, similar to Go. Rust considered virtual threads but chose against that because it requires a more abstracted runtime like Java and Go have. Great preso on this https://www.youtube.com/watch?v=lJ3NC-R3gSI

All the "async" stuff is super poorly named. They mean cooperative multitasking, or I guess "async within a single kernel thread." Yeah multiple kernel threads are asynchronous but "async" doesn't mean that :S

[nextaccountic]

There's an API to call async code in a sync context, it's called block_on. You can just spawn threads and do your block_on on every async API you encounter and go on about your life. Pair it with a good mpsc library for inter thread channels (or just use the stdlib mpsc - even though it's slower and strictly worse than libs, it doesn't matter) and you are good to go

Likewise there's an API to call sync code in async context, it's spawn_blocking (or sometimes block_in_place but, stick with spawn_blocking)