7 ms·

I'm not a Rust user, but this sounds similar to the situation in Scala, where you can call Await.result to block the thread on a Future to get its value. The pr

I'm not a Rust user, but this sounds similar to the situation in Scala, where you can call Await.result to block the thread on a Future to get its value. The problem is that now, any callers of the function that blocks are blocking. So one form of coloring, "async", is converted to another, "blocking". You can use multithreading and synchronization to break of this trap, but now you're in the world we built all of this to escape in the first place. I think this is similar to what the author is describing, in which case, I'd say that function color contagion is a feature of continuation passing style programming, and its sugared variants (futures, async/await), rather than being something that you can say absolutely about a language or a runtime.

thinkharderdev 6y ago
Yeah, Scala doesn't have async/await but you have the same basic issue where if you have one async function (something that returns a Future/IO/Task/etc) then every caller has to also be async (or block on the result and potentially cause all manner of mayhem). I think it's generally less of a problem in Scala though because most libraries/frameworks etc are async by default which makes sense. It's much easier to take a sync effect and fit it into an async process (just wrap the result in Future.successful/IO.pure/etc) than it is to fit an async call into a sync process (you can always do Await.result/IO.unsafeRunSync but it can have some very perverse effects on runtime behavior).