(inspired by thousand’s question about Rx and Kotl...
# random
o
(inspired by thousand’s question about Rx and Kotlin)
k
If you're slowly migrating your codebase from Java to Kotlin (Which is what I think a lot of teams are doing) it makes sense to keep the libraries the same.
Coroutines are also yet another thing to learn on top of Kotlin itself. (I haven't taken the time to learn them either, I should really get started on that)
💯 2
o
Sure I can understand the migration path and learning curve, but for the new experimental project?
r
Personally, I prefer Rx because 1. It has more documentation. 2. I don’t only program in Kotlin, and Rx is more cross-cutting knowledge than co-routines. So there is more bang for my buck to keep using Rx even in new (or experimental) projects.
c
@orangy I don't understand the connection you're making between Rx and coroutines, both address completely different problems.
☝️ 1
👍 3
n
Here is the thing though, there is an implementation of Rx for Coroutines (https://github.com/Kotlin/kotlinx.coroutines/tree/master/reactive/kotlinx-coroutines-rx2). Aka: "You can have your cake and eat it too" 😄. What is the real issue here?
Are people waiting for the RxJava people to do an official Rx implementation for Kotlin Coroutines? 🙄
1
If anything there are too many people trying to use Rx as a silver bullet to solve all concurrency issues, which is a very common problem that is only getting worse. Seems to indicate that Rx doesn't have very good documentation on where to use it, and where not to use it.
r
To that point, the most recent episode of Fragmented has some good discussion on when you should and shouldn't use Rx (as well as how Kotlin can help in some use cases) http://fragmentedpodcast.com/episodes/093-rxjava-intervention-with-dan-lew/
👍 1
t
overuse can be a problem with any technology.
k
They're complementary frameworks...
n
Trevor - So true. Seems with some technology like Rx the overuse goes way too far (one of the extreme cases).
Russell - One good point made about RxJava is that if it is used just for covering concurrency then it is a overkill solution, and a sw developer is better off using async/await instead (or Actors, CSP depending on the concurrency problems that need to be solved in a project).