ghedeon
01/22/2019, 10:40 AMdekans
01/22/2019, 3:11 PMVsevolod Tolstopyatov [JB]
01/22/2019, 4:42 PMghedeon
01/22/2019, 5:13 PMnot today
.dekans
01/22/2019, 8:50 PMghedeon
01/22/2019, 9:01 PMVsevolod Tolstopyatov [JB]
01/23/2019, 8:07 AMzokipirlo
01/23/2019, 8:11 AMActor
works fine, I'm using it in production and don't see any problems. Please don't remove it.dekans
01/23/2019, 8:22 AMactor
a lot.ghedeon
01/23/2019, 8:27 AMmerge
is not available. The next day you introduce channels in your code, you want to combine, merge, etc. People are already asking for combineLatest
on SO: https://stackoverflow.com/questions/49215485/how-can-i-implement-rxjavas-combinelatest-on-kotlin-co-routines-receive-channelCoroutineScope
reference, that supposedly can be omitted with cold streams.)
3. Rx has LiveData interop, Channels don't. https://github.com/Kotlin/kotlinx.coroutines/issues/258
4. Debug Coroutines JVM flag is not available on android. Hard to understand what's going on some times.
5. Debugger fails to stop in consumeEach: youtrack.jetbrains.com/issue/KT-29426?project=kt (btw, consumeEach
will be deprecated, iiric)
6. Testing support is not fully developed. Didn't find a way to properly test my channels code. Dispatcher.setMain
helps, but seems like something similar to InstantTaskExecutorRule
for LiveData is missing. TestCoroutineContext is already obsolete.
7. In general, good portion of api is marked as obosolete.
And that's just from the top of my head. Plus tons of ongoing discussions on Github where it's clear that the API is not stable. Like deprecating flatMap
for ReceiveChannel because it wasn't implemented correctly: https://github.com/Kotlin/kotlinx.coroutines/issues/180
I just can't afford the risk of 9 people pushing the code in production with this level of uncertainty.Vsevolod Tolstopyatov [JB]
01/23/2019, 9:04 AMjava.lang.Stream
to be the replacement for Rx, do you? 🙂
If you are looking for Rx replacement, it is not there yet: https://github.com/Kotlin/kotlinx.coroutines/issues/254
Implementing all operators on top of channels is not our goal for a bunch of reasons:
1) When cold streams arrive, there are chances we should rewrite all channel operators to be consistent with the new model. And this is not something we want to do for a stable API.
2) Cold stream may affect the design and semantics of how to implement operators for channels, even its signature, which is not something backwards-compatible.
And maintaining twice as much as normal operators (and explaining why they are here) is not our goal as well.
3) Without cold streams, but with a lot of Rx-like operators, the average user (which usually do not read any documentation, especially one that explains semantics rather than API) will start to use channels like he uses Rx. It will be much slower, it won’t match Rx semantics and generally it will be a disappointing experience.
4) Some operators are hard or make no sense for hot streams. Flat map issue with the only possible produce
implementation is a good indicator of that.
There is some API that looks rx-ish on top of channels, it is obsolete for exactly these reasons.
So yes, if you want to use channels as direct drop-in Rx replacement, it is not going to work. Channels are a good fit as bridges for [callback-suspension] and [suspension-suspension] worlds and bad for free-form streams transformations and making meaningful business-logic inside of its operators.4. Debug Coroutines JVM flag is not available on android. Hard to understand what’s going on some times.Do you mean
kotlinx.coroutines.debug
property or debug module?
but seems like something similar toI am not very familiar with LiveData, but isn’tfor LiveData is missingInstantTaskExecutorRule
Dispachers.Unconfined
what you are looking for?ghedeon
01/23/2019, 9:42 AMking is dead long live king
, throw away Rx now or you're not cool. I see two options. To take an official strong stance — "people, you're using it wrong!" and close all the issues on github, where people are expecting Rx alike behavior as "won't fix". Or to embrace it. To acknowledge that you're solving similar use cases and eventually to replace Rx. And your actions prove that Kotlin is embracing it. @elizarov
acknowledged, that operators are coming, that LiveData
interop is coming, etc. But I'm pretty sure you're well aware of all this 🙂, you just can't announce it officially, that you compete with Rx, because then people will demand Rx richness and maturity today. A very smart thing to do, if you ask me. (Thank you. Really appreciate your time for participating).Do you meaniiric,property or debug module?kotlinx.coroutines.debug
kotlinx.coroutines.debug
is ok, it's enabled for debug builds automatically, and DebugProbes
doesn't work on Android.
isn’tI meant similar towhat you are looking for?Dispachers.Unconfined
RxAndroidPlugins
and InstantTaskExecutorRule
for LiveData, but seems like it's already decided to not implement it and go with DI: https://github.com/Kotlin/kotlinx.coroutines/issues/102.Vsevolod Tolstopyatov [JB]
01/23/2019, 3:39 PMI see two options. To take an official strong stance — “people, you’re using it wrong!” and close all the issues on github, where people are expecting Rx alike behavior as “won’t fix”. Or to embrace it.We will try to do both 🙂 Cold streams are our next biggest feature and we want it to be stable and production-ready Rx replacement, including operators. Hopefully, when cold streams arrive (and start its hype), most of the “issues” with channels will go away, the rest is an educational problem.
We will try to fix it with AspectJdoesn’t work on AndroidDebugProbes
it’s already decided to not implement it and go with DIRight, only the main dispatcher is mockable, a rationale is here: https://github.com/Kotlin/kotlinx.coroutines/issues/810#issuecomment-439927255