Inside Rust's Async Transform
Async/await pattern always confuses me, someone please let me know if I get this right:<p>First, async/await does NOT mean "threading" or "multiprocessing" or "concurrency".  It simply means "using a state machine to alternate between tasks, which may or may not be concurrent."  Right?<p>Further, in Javascript, futures and async are utilized heavily because we so frequently need to wait for IO events (i.e.: network events) to complete, and we don't want to block execution of the entire page just to wait for a IO to complete.  So the JS engine allows you to fire off these network events, do something else in the meantime, and then execute the "done" behavior when the IO is complete (and even in this case, we might not be concurrent, because ).<p>That makes sense to me.<p>But say I have written something in Rust that makes use of async/await.  And say there is absolutely no IO or multithreading.  Say I have some awaitable function called "compute_pi_digits()" that can take arbitrarily long to complete but does not do IO, it's purely computational.  Is there any benefit to making this function awaitable?  Unless I actually spawn it in a different thread, the awaitable version of this function will behave identically to if it were NOT awaitable, correct?<p>And one last idea: the async/await pattern is becoming so popular across vastly different languages because it allows us to abstract over concepts like concurrency, futures, promises, etc.  It's a bit of a "one size fits all" regardless of whether you're spinning up a thread, polling for a network event, setting up a callback for a future, etc?