| >It doesn't! No one is forcing anyone to use async. Well, hang on there... this isn't entirely fair. Rust does not force you to be async, but the community in some ways pushes you to be async even where it might not make sense for it to be the default. I can't say for certain (and this is all my opinion, to be clear) but it feels like this started happening when async-fervor hit its peak. My go-to example is reqwest, which if you want a blocking HTTP call, still just needs all of Tokio in the background. I find it really odd that the blocking API is just a wrapper for a finagled async API; if I'm choosing the blocking one, I probably don't want Tokio in my project. There are other HTTP request libraries, to be clear - but they're often less battle tested and/or have their own lurking bugs. Reqwest is the de-facto one and it'd be nice to be able to use it without the heaviness it brings in. Depending on the domain you're programming in, it can often feel like async-by-default is the norm. It can be frustrating in Rust. (It's nowhere near enough to deter me from using the language, mind you) |
I think a blocking implementation being a `await(async impl)` is typically fine...
the problem with that is the lack of async interop in the current state of things, more than the async runtime which mostly gets compiled away.