RxKotlin - Pure implementation for JVM, Native, JS #115
Comments
|
Yes, this is a discussion we recently started having on the #rx channel in Kotlin Slack. While we initially thought it would be impractical to do a pure Kotlin implementation due to the amount of work, Roman from JB enlightened us about how coroutines could be used to make an Rx implementation trivial. I haven't dived into this deeply yet but from what he told us it sounds promising. It is definitely something we want to explore and we welcome any involvement in early discussions as well as implementation if we decided to go forward. |
|
I prefer As an option, we could use https://github.com/akarnokd/RxJava3-preview as a starting point, since it's already modular. |
|
More lightweight how?
…On Sat, Apr 29, 2017, 8:25 AM Stepan Goncharov ***@***.***> wrote:
I prefer rxKonan😁 Pure kotlin reactive extensions implementation would
be more lightweight and could definitely take advantage from coroutines.
As an option, we could use https://github.com/akarnokd/RxJava3-preview as
a starting point, since it's already modular.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#115 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEEEfalIHGtRrQdFMY3cbqMeKsLW8O_ks5r0yxNgaJpZM4NKDx5>
.
|
|
Theoretically by using inline functions and Kotlin stdlib extension functions overall method count of library itself should be less than rxJava's equivalent. |
|
@stepango @JakeWharton also lightweight in that a coroutine-backed RxKotlin would use fibers instead of threads. Coroutines naturally handle backpressure so we would not have any overhead for that as well. |
|
Not quite sure why that's really different or inherently more lightweight
than a scheduler. On the JVM coroutines are backed by threads which loop on
a queue just like schedulers.
…On Sun, Apr 30, 2017, 11:24 AM Thomas Nield ***@***.***> wrote:
@stepango <https://github.com/stepango> @JakeWharton
<https://github.com/JakeWharton> also lightweight in that a
coroutine-backed RxKotlin would use fibers instead of threads. Coroutines
naturally handle backpressure so we would not have any overhead for that as
well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#115 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEEEWKFIKcfliHus8CQA0Oj7rOBSTObks5r1KejgaJpZM4NKDx5>
.
|
|
Whether or not it's better or worse off, with the projects I'm starting being as cross-platform/cross-environment (JVM/JS/Native) as possible (honestly still uncomfortable trying something like native and how that will muck with what kind of libraries I can build or share between code bases), and already tasting some of RxKotlin, I'll just throw my hat in to say that a pure Kotlin implementation would make me love this project even more; and knowing just how advanced I already sort-of feel in Kotlin I'd like to know how really advanced I am when I inspect this project's source code and progress. Anyway, just trying to steer this toward a: let's get it implemented. Thanks! |
|
I agree, regardless there will at least be an easier to use, more maintainable Rx implementation in pure Kotlin. I'm kind of busy for the next week or two with kotlin-statistics and the Packt RxJava book. Im also shooting a Talking Kotlin episode with JetBrains on Kotlin for Data Science. After i get all that done, I will start looking at making an implementation. |
|
Just started to play around RxJava3-preview(Basically it's just rxJava2 but separated to 4 modules). Finally, manage to replace Action by Function0. And all tests still pass 💪https://github.com/stepango/RxKotlin3-preview |
|
Hmmm... interesting. Do you think that a fork will be the easiest approach? My intuition and research suggests that RxKotlin with a coroutine implementation may take a drastically different route as it doesn't need backpressure implemented. I may be experimenting from scratch just to see what emerges with that approach: |
|
Initially my plan was to make this implementation useful and than move internal implementation to Coroutines. |
|
Alright cool, let me know what you find and we will compare notes as we get some progress. |
|
My first goal with https://github.com/stepango/RxKotlin3-preview is solving #103 by replacing |
|
That prevents SAM conversion. They should be replaced with lambda types.
…On Wed, May 10, 2017 at 10:23 PM Stepan Goncharov ***@***.***> wrote:
My first goal with https://github.com/stepango/RxKotlin3-preview is
solving #103 <#103> by
replacing io.reactivex.functions.* with kotlin.functions.*
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#115 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEEEYmyI7ULWkhSP4CPpAdIdC7BYk0fks5r4nEcgaJpZM4NKDx5>
.
|
thomasnield
changed the title
|
I have a POC in the works here. Need to figure out how to implement backpressure and cancellation https://github.com/thomasnield/rxkotlin-poc |
|
So I talked to a number of folks to get an idea how hard it would be to make an RxKotlin implementation that would work on the JVM, JS, and Native. It's a lot to take on, and there's a lot of contingencies that need to take place. The coroutines library will need to be implemented for Kotlin JS and Native, which it sounds like JB has not even started exploring yet. This leaves this initiative largely in limbo. When those contingencies finally come into place, it will be quite a bit of work modularizing RxKotlin in a way that allows an implementation for each platform. The only thing that could immediately be worked on then is RxKotlin for JVM, whose benefit is largely marginalized due to the issue above. RxJava 2 is benchmarked and optimized heavily already, and while it carries a few inconveniences being in Java, I believe the matter of using time and energy of eliminating those inconveniences with a pure implementation is debatable. If someone does want to pursue a JVM implementation now, it would be wise to modularize it to allow the other platforms once they are ready. In summary, I believe it's too soon to start working on a pure RxKotlin implementation due to coroutines not yet existing on multiple platforms. If someone wants to work on it for the JVM, have at it. I may still tinker with my small POC but will likely not do anything more at the moment. If anybody has clever ideas or wants to show their experiments, please share with us. In the interim, I'm going to focus on smaller, more attainable initiatives this year. |
|
New article about this by @akarnokd https://akarnokd.blogspot.hu/2017/09/rewriting-rxjava-with-kotlin-coroutines.html |
|
For the record, Jake Wharton has been doing a lot more experimentation on this front. It seems multi-platform efforts would be better directed there: |
|
For those following this thread, it looks like cold streams are planned for the Kotlin coroutines library, which would allow for stream apis that would be more familiar to someone coming from RxJava than coroutines. If done well, it might reduce / remove the need for something like this. |
|
I want use the rx at kotlin native.Any plan for this? |
|
Take a look at https://github.com/badoo/Reaktive it's almost production ready 🤗 |
|
Are there any plans for kotlin multiplatform? |
Lately we have seen Kotlin/Native tech preview as well as Kotlin JavaScript compiler. As I understand it one of main advantages of developing in these techs would be to be able to have modules written in pure Kotlin (No Java standard library etc.) shared between projects for different platforms - iOS, Android, Web.
Since this library is just a wrapper around RxJava it would be only possible to use it on Android or any JVM environment so any module using it wouldn't be shareable between platforms.
There are already corresponding Reactive Extensions projects for other two platform RxSwift and RxJs so there could be some abstraction built to just use according Rx library on each platform but I really doubt it would work since these libraries just share some common principles with RxJava and not all operators are semantically the same.
Completely rewriting RxJava in Kotlin wouldn't be the easiest task I guess but certainly the most sought after.
Any thoughts on this?
The text was updated successfully, but these errors were encountered: