Any rough estimations from officials of when Chann...

# coroutines

[ghedeon]

Any rough estimations from officials of when Channels are going to be production ready? The quarter of the year maybe. (Note: it's not about push or faster delivering, it's about roadmaps and planning)

[dekans]

They are production ready. But the API will change to support cold streams iirc.

[Vsevolod Tolstopyatov [JB]]

They are production ready. Some API is experimental because we are not sure we won’t change it, but core functionality (send/receive, iteration, close) is stable and production ready

[ghedeon]

I love kotlin as much as the next guy here and I'll use channels in my pet projects. But after a week of active research, reporting issues, exploring the github WIP discussions about upcoming changes, I officially advised my team to not use them in production (yeah, bring your pitchforks 🙂). It's not ready, at least on Android. The latest issue I reported not so long ago as today morning. Maybe I'll post here a gist with some findings, but overall impression is not today.

[dekans]

What's wrong on Android? I use Kotlin/Coroutines on Android and it"s OK.

[ghedeon]

Define coroutines. The topic is about channels. Nothing wrong with coroutines, we use them in production.

[Vsevolod Tolstopyatov [JB]]

Constructive feedback is always welcomed, it really helps to build a better product.
Feel free to share your concerns and pieces you think are making them unstable.

[Vsevolod Tolstopyatov [JB]]

Also, try not to mix issues about channels (they should be very rare), actors (obsolete), channel operators (obsolete) and cold streams (not yet designed) 🙂

[zokipirlo]

Actor works fine, I'm using it in production and don't see any problems. Please don't remove it.

[dekans]

@ghedeon correct! What's wrong with channels?
I use them to remove some callbacks, and it works pretty well.
I also use them via actor a lot.

[ghedeon]

let's take it slowly, in a constructive manner. What do you mean channels operators issue is obsolete?

[ghedeon]

https://github.com/Kotlin/kotlinx.coroutines/issues/437

[ghedeon]

even the simple merge 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-channel

[ghedeon]

Seriously, guys, I understand that you're biased, and channels might work in one trivial example out of 10 that were covered by RxJava before, but isn't it better to be honest here? People are getting hyped on "RxJava == Coroutines" only to face the disappointing reality later.

[ghedeon]

1. Operators. Only collection operators available.
2. Cold streams. (Also, because it's not implemented, you're doomed to pollute your API with CoroutineScope 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.

[ghedeon]

Also, the lack of good examples: https://github.com/Kotlin/kotlinx.coroutines/issues/945

I'm not saying it's the JB duty to write examples, but the absence of apps that use channels (ironically, from the KotlinKonf speakers itself) is a sign of low adoption (to date). Which means, again, high risk in production.

[Vsevolod Tolstopyatov [JB]]

I’ve understood your concerns, so let me clarify:

Channels are not replacement for RxJava. Neither we advertise them as Rx replacement, nor they are. Channels are hot-sources of the data, while RxJava is mostly cold.
Channels are just blocking queues on steroids, where instead of blocking senders/receivers suspend. You do not expect, say, java.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.

[Vsevolod Tolstopyatov [JB]]

On some specifics:

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 to InstantTaskExecutorRule for LiveData is missing

I am not very familiar with LiveData, but isn’t Dispachers.Unconfined what you are looking for?

[ghedeon]

@Vsevolod Tolstopyatov [JB] I hear you, but here is the deal. People used to have one stream abstraction — Rx, now they have another, but with fewer operators. You just can't avoid the comparison between the two. I don't think it's physically possible. I bet you guys are already tired of people bringing Rx to the discussion over and over again. And I don't judge them. It will keep coming. Medium is flooded with articles king 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).

[ghedeon]

Do you mean kotlinx.coroutines.debug property or debug module?

iiric, kotlinx.coroutines.debug is ok, it's enabled for debug builds automatically, and DebugProbes doesn't work on Android.

isn’t Dispachers.Unconfined what you are looking for?

I meant similar to 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]]

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.

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.

DebugProbes doesn’t work on Android

We will try to fix it with AspectJ

it’s already decided to not implement it and go with DI

Right, only the main dispatcher is mockable, a rationale is here: https://github.com/Kotlin/kotlinx.coroutines/issues/810#issuecomment-439927255

[Vsevolod Tolstopyatov [JB]]

Thank you for the feedback! It is constructive and very valuable for us