# Rewriting RxJava with Kotlin Coroutines?

DevFeed: [Rewriting RxJava with Kotlin Coroutines?](<https://devfeed.tech/articles/rewriting-rxjava-with-kotlin-coroutines-24814.md>)

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

Author: David Karnok (noreply@blogger.com)

Published: 2017-09-09T15:16:00Z

Content type: opinion

Language: en

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

Topics: [Coroutines](<https://devfeed.tech/topics/coroutines.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [kotlin-coroutines](<https://devfeed.tech/topics/kotlin-coroutines.md>), [reactive](<https://devfeed.tech/topics/reactive.md>), [Streams](<https://devfeed.tech/topics/streams.md>)

Tags: [callback](<https://devfeed.tech/tags/callback.md>), [cancellation](<https://devfeed.tech/tags/cancellation.md>), [coroutine](<https://devfeed.tech/tags/coroutine.md>), [coroutines](<https://devfeed.tech/tags/coroutines.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-coroutines](<https://devfeed.tech/tags/kotlin-coroutines.md>), [library](<https://devfeed.tech/tags/library.md>), [reactive](<https://devfeed.tech/tags/reactive.md>), [reactive-streams](<https://devfeed.tech/tags/reactive-streams.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [scrabble](<https://devfeed.tech/tags/scrabble.md>)

## AI overview

The article explores whether a declarative-reactive library can be implemented with Kotlin coroutines as an alternative to RxJava. It examines coroutine abstractions, operator design, cancellation, lazy versus eager execution, and the potential trade-offs for library developers and users.

## Source excerpt

Introduction Someone influential stated that RxJava should be rewritten with Kotlin Coroutines. I haven't seen any attempt of it as of now and declaring such a thing to be (not) worth without actually trying is irresponsive. As we saw in the earlier post and the response in the comment section, following up on the imperative-reactive promise leads to some boilerplate and questionable cancellation management, and the idiomatic Kotlin/Coroutine enhancement suggested is to ... factor out the imperative control structures into common routines and have the user specify lambda callback(s); thus it can become declarative-reactive, just like RxJava interpreted from a higher level viewpoint. Kind of defeats one of the premises in my understanding. This doesn't diminish the power of coroutine-based abstraction but certainly implies a relevant question: who is supposed to write these abstract operators? One possible answer is, of course, library writers who not only have experience with abstracting away control structures but perhaps wield deeper knowledge about how the coroutine infrastructure can be utilized in certain complicated situations. If this assumption of mine is true, that somewhat defeats another premise of coroutines: the end user will likely have to stick to writing suspendable functionals and discover operators provided by a library most of the time. So what's mainly left is to see if implementing a declarative-reactive library on top of coroutines gives benefits to the library developer (i.e., ease of writing) over hand crafted state-machines and (reasonable) performance to the user of the library itself. The library implementation Perhaps one of the more attractive properties of RxJava is the deferred lazy execution of a reactive flow (cold). One sets up a template of transformations and issues a subscribe() call to begin execution. In contrast, CompletableFuture and imperative Coroutines can be thought as eager executions - in order to retry them one has to