did I miss something are there any gotchas

Question

Erik · Answer

Quite a complete summary dictionary I d say that the gotcha is that both require a certain mental model of what s going on Both can be daunting or very logical depending on what you like

ursus · Answer

From what I see the mental model is really the same with only different names

Erik · Answer

For me personally for example the Rx stuff looks daunting for newbies while the coroutine stuff is a bit easier to read and to get started with

Erik · Answer

It s a matter of style and that s partly subjective

ursus · Answer

Yea lets discount that I already know rx

Erik · Answer

The Structured Concurrency paradigm is important to keep in mind when working with coroutines

ursus · Answer

Thats just scoping of asynchrony disposables composite disposables do that no

Erik · Answer

And the Job state machine especially when dealing with exceptions and cancellation is something that may be difficult

ursus · Answer

is it the `launch` vs `ąsync` thing

Erik · Answer

Amongst others yes

ursus · Answer

I ll take a note thanks

Erik · Answer

The child parent relationship of jobs

Erik · Answer

Who cancels who and when

Erik · Answer

Who handles exceptions

Erik · Answer

The happy path is easy Dealing with exceptions is the important work Also concurrency isn t free so cancelling work and making it cancellable is also important Not different than with Rx but still the implementation details are an interesting subject

ursus · Answer

so in general whether parent should be also canceled transitively canceling all children

Erik · Answer

Yes that s the default but you can control that

ursus · Answer

I see pretty much same with rx

Erik · Answer

Also cooperative cancellation is a topic you should read about when a job is cancelled it can keep running if it needs

Erik · Answer

But it should stop working ASAP but a bad impl would keep running

ursus · Answer

Sounds the same as wraping a 3rd party api and not using `setCancelable ` in rx

ursus · Answer

and blocking code would also not cancel same

Erik · Answer

I d advice you to try and build your next feature using coroutines Or refactor a simple one It sounds like you ve got this mental model of a synchronous streams and concurrency good enough already

ursus · Answer

Yea I was wondering if I should do that + adapters back to rx while sharing threadpools behind dispaters schedulers there shouldnt be much of a overhead right

Erik · Answer

Any coroutine compatible code e g a `suspend fun x ` can be called from the current thread using `runBlocking x ` That s your adapter if you want to call these suspending functions and wrap them in Rx constructs

Erik · Answer

I believe that the Kotlin coroutines lib also provides some adapters e g to convert a `Flow lt T gt ` to `Observable lt T gt ` and vice versa

ursus · Answer

yea those exists I meant runtime overhead with not sharing actual threads

Erik · Answer

Maybe in a separate dependency but it probably is a very thin wrapper between the libs

Erik · Answer

Both RxJava and Kotlin coroutines are optimised quite a bit already The most overhead would be setting up the thread pools for the first time probably Once the schedulers and dispatchers underlying thread pools have spun up they are probably cheap to use

Erik · Answer

It should be possible to create your own dispatcher from a thread or thread pool maybe even from an Rx scheduler

Erik · Answer

I have no experience with this though

Erik · Answer

That way you could truly share the same threads

Erik · Answer

Found it <https kotlin github io kotlinx coroutines kotlinx coroutines rx2 kotlinx coroutines rx2 io reactivex scheduler as coroutine dispatcher html>

ursus · Answer

nice thats what I need

Erik · Answer

That site is what I use a lot for documentation on coroutines in general if you hadn t found it yet

ursus · Answer

thanks