[vc8f6vVV]

Interesting, in the Java world Thread.stop is deprecated too: https://docs.oracle.com/javase/7/docs/technotes/guides/concu... Which means there is no good way to actually stop a thread involuntary. Of course in most simple apps it's not a big deal, but I would not do it in long-running apps.

OTOH in Rust async model is based on polling. Which means that poll may never block, but instead has to set a wake callback if no data is available. So there is no way to interrupt a rogue task and all async functions should rely on callbacks to wake them (welcome to Windows 3.1, only inside out!). Thread model is much more lax in this sense, e.g. even though my web server (akka-http) is based on futures, nothing prevents me from blocking inside my future, in most cases I can get away with it. As I understand it's not possible in Rust async model, I can only use non-blocking async functions inside async function. So in reality you don't interrupt or clean up anything in Rust when a timeout happens, you simply abandon execution (i.e. stop polling). I wonder what happens with resources if there were allocated.

[insanitybit]

> As I understand it's not possible in Rust async model,

You can block, you're just going to block all other futures that are executed on that same underlying thread. But all sorts of things block, for loops block.

This is the same as Java, I believe. Akka also has special actors called IO Workers that are designed for blocking work - Rust has the same thing with `spawn_blocking`, which will place the work onto a dedicated threadpool.

> So in reality you don't interrupt or clean up anything in Rust when a timeout happens

You don't interrupt, you are yielded to. It's cooperative.

> I wonder what happens with resources if there were allocated.

When a Future is dropped its state is dropped as well, so they are all freed.

[vc8f6vVV]

If you block your timer goes out the window, right? Because the poll will never get there until the blocking call is done. So yeah, you can block, but it will disrupt the whole chain, including tasks above yours up to await. Similar to Erlang VM where the language itself yields (e.g. there are no loops and every recursive call is effectively a yield), but if you add a C module and are careless enough to block, the whole EVM blocks. So no, if you want to use async you shouldn't block. For loops? Nope, not if they take long time for the same reason, you may want to break them down to smaller chunks ("long" depends on other tasks and expected latency).

Having said that, Erlang exists and doing well, so async is as good as any model designed for special cases. But this discussion basically answers the question

> Why don’t people like async?

Because not everybody (which means a majority of developers) needs this complexity. And the upward poisoning means that I can't block in my function if my web server is based on async, which affects everybody who is using it.

[insanitybit]

> If you block your timer goes out the window, right?

This is the case in every language.

> So no, if you want to use async you shouldn't block.

Everything blocks. The dosage makes the poison.

> For loops? Nope, not if they take long time for the same reason

You would want to add a yield in your loop, yes. Async loops `while let Some(msg) = stream.next().await` will work well for this.

> And the upward poisoning means that I can't block in my function if my web server is based on async, which affects everybody who is using it.

To be clear, you can definitely block as much as you want in those frameworks, you just need to understand that you'll block the entire thread that's running your various futures. That's not that big of a deal, you'd have the exact same issue with a synchronous framework. Blocking in an OS thread still blocks all work on that thread, of course.