# RxJava vs. Kotlin Coroutines, a quick look

DevFeed: [RxJava vs. Kotlin Coroutines, a quick look](<https://devfeed.tech/articles/rxjava-vs-kotlin-coroutines-a-quick-look-24815.md>)

Original publisher: [Read original article](<https://akarnokd.blogspot.com/2017/09/rxjava-vs-kotlin-coroutines-quick-look.html>)

Author: David Karnok (noreply@blogger.com)

Published: 2017-09-05T15:11:00Z

Content type: comparison

Language: en

Sources: [Akarnokd - Advanced RxJava](<https://devfeed.tech/sources/akarnokd-advanced-rxjava.md>)

Topics: [kotlin-coroutines](<https://devfeed.tech/topics/kotlin-coroutines.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Coroutines](<https://devfeed.tech/topics/coroutines.md>), [reactive](<https://devfeed.tech/topics/reactive.md>), [Usability](<https://devfeed.tech/topics/usability.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [blocking](<https://devfeed.tech/tags/blocking.md>), [business-logic](<https://devfeed.tech/tags/business-logic.md>), [code](<https://devfeed.tech/tags/code.md>), [coroutine](<https://devfeed.tech/tags/coroutine.md>), [coroutines](<https://devfeed.tech/tags/coroutines.md>), [experimental](<https://devfeed.tech/tags/experimental.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-coroutines](<https://devfeed.tech/tags/kotlin-coroutines.md>), [main-thread](<https://devfeed.tech/tags/main-thread.md>), [programming](<https://devfeed.tech/tags/programming.md>), [reactive](<https://devfeed.tech/tags/reactive.md>), [reactive-programming](<https://devfeed.tech/tags/reactive-programming.md>), [retry](<https://devfeed.tech/tags/retry.md>), [runblocking](<https://devfeed.tech/tags/runblocking.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [suspend](<https://devfeed.tech/tags/suspend.md>), [thread](<https://devfeed.tech/tags/thread.md>), [timeout](<https://devfeed.tech/tags/timeout.md>), [zip](<https://devfeed.tech/tags/zip.md>)

## AI overview

This article compares RxJava and Kotlin Coroutines through an example involving delayed unreliable services, timeouts, cancellation, retries, and combining results. It emphasizes usability over raw performance and describes coroutine code as more sequential and synchronous-looking, while noting that coroutines were experimental at the time.

## Source excerpt

Introduction Does Kotlin Coroutines make RxJava and reactive programming obsolete? The answer depends on who you ask. Enthusiasts and marketing departments would say yes without hesitation. If so, sooner or later developers would have to convert Rx code into coroutines or write something with coroutines from the start. Since Coroutines are currently experimental, there is always the prospect deficiencies, especially regarding the overhead, will be resolved eventually. Therefore, this post will focus more on usability than raw performance. The scenario Let's say we have two functions imitating unreliable service: f1 and f2, both returning a number after some delay. We have to call these services, sum up their returned values and present it to the user. However, if this doesn't happen within 500 milliseconds, we don't expect it to happen reasonably faster, thus we'd like to cancel and retry the two services for a limited amount of time before giving up after some number of retries. The Coroutine Way Programming via coroutines feels like programming with the traditional ExecutorService- and Future-based toolset with the difference that the underlying infrastructure will use suspension, state machine(s) and task rescheduling instead of blocking a thread. First, we need the functions that exhibit the delaying behavior: suspend fun f1(i: Int) { Thread.sleep(if (i != 2) 2000L else 200L) return 1; } suspend fun f2(i: Int) { Thread.sleep(if (i != 2) 2000L else 200L) return 2; } Functions that participate in a coroutine execution should be declared with the suspend keyword and executed within a coroutine context. For demonstration purposes, the logic will sleep for 2 seconds if the parameter supplied to the functions is not 2. This will give a chance to the timeout logic to kick in yet the 3rd attempt to succeed before the timeout. Since going asynchronous usually ends up leaving the main thread, we need a way to block it until the business logic completes before letting the