Coroutines may be seen as a replacement of reactive programming. Both of them offer the possibility to create asynchronous applications although in a very different way. Does it still make sense to use reactive programming in Kotlin? Or can we just stick with coroutines and forget all about other asynchronous applications approaches? Or maybe we can mix both of them, take their best parts and come up with a solution which is superior to any of the two? In this session we'll learn the differences between coroutines and reactive programming. We'll see when one shines and the other... is not so great. We'll look under the hood to find out the reasons behind some design decisions and how those decisions affect performance and interoperability. We'll try to decide when we should use coroutines and when the reactive programming model is better.