@elizarov why did kotlin not go the go route with coroutines and having a scheduler deal with moving things off onto other threads? Was the aim to give more fine grained control to the developer?

You're partly right regarding giving more fine grained control. Kotlin strives to be explicit. That's why you need to be specific about where a coroutine is launched, where you want to switch execution context (which is not just about dispatcher BTW), and that's why we have structured concurrency in kotlinx.coroutines.

That. And we also needed to support single-threaded UI frameworks like Swing and Android.