they're complimentary not competition

What can Rx solve that Coroutines cannot?

multi-value cold push

RxJava is an abstraction

cold stream are planned feature.

i'm aware as evidenced by my participation in that thread

indeed^^

RxJava basically contains a tiny implementation of coroutines and there's no reason that a version of RxJava couldn't be built on top of Kotlin coroutines to great benefit

But once kotlinx.coroutines will have cold stream. What use case would be answered by rxJava only?

its operator collection

Its operator collection can also be added to kotlinx.coroutines, right ?

kotlinx.coroutines has even, if smaller an operator collection too. And RxJava operators are anyway not usable with kotlin channels, so the rx operator collection doesn't help if you use coroutines.

sure. then we've just reinvented RxJava thus proving they're complimentary concepts and not competing and we can stop these silly questions from being asked over and over

I think it is an interesting question. And it must be answered before going for coroutines. And if the answer is "they are complimentary" this is okay, but then the question becomes: "How do they complement each other? For what task should I chose one or the other?"

When most people talk about coroutines or RxJava they don't actually care about the implementation of the library they care about the programming style that it affords

Okay. I agree with everything you said. But, to me, it means that they do compete. Otherwise, for what task would you still use Rx?

@Jonathan I've been experimenting with a library that gives the user an API similar to Rx, but with an under the hood implementation using Coroutines to enable concurrent data flows. The implementation to enable concurrent reactive programming using coroutines is an order of magnitude simpler than trying to manage that with threads https://github.com/caleb-allen/Konko-Flow

@Caleb Allen Yes. I'm aware that it is possible to recreate an "rx-like" library based on coroutines. There is another similar project too, if you're interested: https://github.com/pull-vert/reactivity. But why would I need such library? What use-case does it solve better than plain coroutines with kotlinx.coroutines?

Oh we're linking Rx coroutine libraries? https://github.com/JakeWharton/Reagent/

My use case/experiment has been using rx-like operations to wrap these operations into easy to use dispatchers that take care of concurrency for me.

Rx & coroutines operates at a different level of abstraction IMO, they provide different ways of reasoning about the code, and they just partially overlap each other. First, I’d say Rx is not primarily concerned with concurrency. Hold on, of course it has built-in tools to handle concurrency and asynchronous behaviours, but that’s not the main/only reason to use Rx. Rx is more about reasoning in terms of streams. Rx is more about expressing and representing the business logic of your application in terms of manipulation and combination of these streams (usecases becomes actually observable transformers). I would consider more appropriate to compare Rx to something like say FRP (Rx intentionally is NOT by construction a realisation of FRP in the sense of the Elliott’s FRP work) or compare it to a more traditional, imperative, state machines. Rx is more about “monadic” chainability, push-based patterns, etc and it’s highly influenced by concepts borrowed from functional programming and category theory. Then, As a matter of fact, Rx also has another degree of freedom, namely the Scheduler, an interesting abstraction on top of threads, and people can exploit this degree of freedom to achieve asynchronous behaviour. I guess (but I’ve never tried myself) there is nothing that in principle prevents someone to write a Rx scheduler on top of coroutines and power the whole Rx infrastructure with coroutines. CSP/channels etc that kotlin implements on top of coroutines are not a replacements for monadic composition, they are a model to reason about concurrent behaviour (as they are actors)

Kotlin Sequences and coroutines channels allow to reason in term of streams. Business logic can be express as manipulation and combination of theses streams. Coroutine dispatchers allow same abstraction as Rx schedulers. I know there are differences. But, I'm not aware of a concrete use-case for which Rx would help more than sequences or coroutines. If you know one, please share it, I'm genuinely interested.

multi-value cold push sources. neither channels nor sequences can model this

Ok, so you'r answer is "as soon as kotlinx.coroutines will provide cold stream, as they are planning to, there won't be such use-case."?

well except for the lack of operators that will be available and need to be rewritten

Yes but I cannot use rx operators with coroutines channels anyway. And if I miss an operator with channels it is usually very easy and straight forward to implement it myself. So bottom line, if I have kotlin coroutines, I don't need rx.

you seem to be conflating rx with RxJava

Yes, indeed I'm conflating them, sorry for that. Every time I said "rx" I meant "RxJava"

Then I agree with you! Once we have that, you shouldn't need to use the library unless you're interoperating with something that requires it.

I know my question was a bit polemic. But I had problems in porting some Rx code to coroutines, such as setting a piece of code to react to bluetooth data only when that the remote device send them.

@alucard Was it Bluetooth Classic or Bluetooth Low Energy?

Classic Bt

channels?