Supported languages

[cbornet]

Sorry in advance if this is not the good channel to ask questions.

This project looks very promising and I'm particularly interested in the RSocket-RPC that could be a very good challenger to gRPC. gRPC has some shortcomings especially as you need a proxy for the browser based implementation. Also, even if gRPC has a pull-based throttle mechanism quite similar to Reactive Streams, it's not easy to plug them together (reactive is never easy...).

But to win the war against gRPC, one very important point IMO will be the availability of implementations in all kind of languages.
So can you tell what languages are planned to be supported ? For instance, I'm particularly interested in Python and C#/.NET core.
Also it seems that for a good end-to-end experience, a reactive-streams lib should be available. I understand that this goes far beyond the scope of this project but do you know if there is work in this field ? For instance in the Rx family libs ?

[yschimke]

On the languages front: hopefully all :)

Currently supported:
Java: https://github.com/rsocket/rsocket-java
C++: https://github.com/rsocket/rsocket-cpp
JS: https://github.com/rsocket/rsocket-js
Kotlin (JVM): https://github.com/rsocket/rsocket-kotlin

older (unsupported): python, go.

But each platform has their own distinct reactive-streams libs. I think ideally each would use a well supported reactive-streams for that platform. In the case of java that is Project Reactor from Spring, which also supports https://github.com/reactive-streams/reactive-streams-jvm and java 9 streams.

I don't think it is clearcut for C++ or JS, so there it's built internally.

[cbornet]

On the languages front: hopefully all :)

Yes but are there any plans on this ? Which will be the next supported languages ? I guess Swift is a must-have for mobile apps...

Also, maybe naive question : it seems the Kotlin and Java impl are completely unrelated. Shouldn't there be a mutualised core and only API bindings for each language ?

[robertroeser]

@cbornet We - Netifi - are actively developing a C#/.NET version.

The Kotlin version is based on the Java version, but doesn't rely on it because the Java version is targeted for 1.8 vs the Kotlin version which is for Android. Eventually it may go away and we will just have Kotlin bindings.

[sdeleuze]

For Kotlin/JVM, I agree that for long term a dedicated library does not make sense and should probably be turn into a Kotlin bindings on top of the Java version.

But for Kotlin in general, something that would make sense on long term would be turning it to a Kotlin multiplatform library to be able to target Kotlin/JVM, Kotlin/JS, Kotlin/Native and the potential WebAssembly support with most of the same codebase. It is still too early for that since Kotlin/kotlinx.coroutines#254 is still not resolved and maybe impact how back pressure is managed in Coroutines, but I think it is worth to evaluate. I think it could be possible to find stakeholders in Kotlin community to move forward this approach.

Notice that @jdemeulenaere is experimenting around related idea via its https://github.com/jdemeulenaere/krpc experiment.

[cbornet]

I see that .NET is now supported. Awesome work 👍 !

[smaldini]

I should actually produce a matrix to display on the website, I'm running behind schedule on that sorry. Go effort has also recently resumed.

[sdeleuze]

I have written a proposal to reboot rsocket-kotlin as a Kotlin multiplatform project that leverages the recently announced Flow type, see rsocket/rsocket-kotlin#59 for more details.