Suspending over blocking

[ookami_kb]

Which is effectively creating a new thread. Threads are heavy objects in terms of memory and performance.
…
Essentially, Coroutines are light-weight threads but we don't create any real thread.

Actually, both examples with Rx and coroutines are doing the same: run the task on a shared thread of pools.

[Biggy_B]

You can check on which thread each peace of code is running with
println("Thread is ${Thread.currentThread().name}")

For Rx it would be 'Thread is RxComputationThreadPool-1'
For Coroutines 'Thread is main'

As you can see Coroutines don't create any additional threads

[ookami_kb]

For Coroutines 'Thread is main'

Well, yeah, if you're launching it in main thread dispatcher's context, but by default it runs in a shared thread pool.

You can achieve the same result with Rx by using observeOn/subscribeOn. Moreover, you'll have to subscribe on main thread if you're working with UI, otherwise you'll get an exception, as you can't modify views from any other thread.

My point is that it's incorrect to contrapose rx and coroutines in terms of threads management – both can be launched on main thread / shared pool of threads / separate thread, there's no difference between them in this case.