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)

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

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

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

.

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

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

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.

Actor

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

@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.

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

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] 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).

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