For the JVM now there's Kotlin Coroutines. They also have the concept of suspension.
One nice thing about Kotlin Coroutines, there are libraries with basic implementations, but actually it is an language API to design suspending operations, you can use any execution model behind it, heavy threads, lightweight threads, reuse your engine loop system, it doesn't matter, it all will look like sync procedural code if you want. Or Actors, Channels, Generators.
Often people ask me why I like Kotlin Coroutines so much and dropped RxJava totally, instead of using them together, and my answer it's mostly that Rx is hard to read and reason, there's cognitive overload every time you need to read it. Doesn't matter if you know it well, you will always be thinking about the execution, while with suspending async model, I will just read the business logic line by line, as usual. I found it reeeally easier for juniors to get into, even when mixing some little reactive, overall they were faster solving problems with less async bugs.
When I meet the suspending paradigm, I learnt how much I was missing sync "old style code" and didn't know.
I agree with you, too much reactiveness may be hurtful. But I still love it for UI bindings, better yet for bidirectional bindings. I guess it's all about balance ¯_(ツ)_/¯
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great write-up, sharing with my team :)
For the JVM now there's Kotlin Coroutines. They also have the concept of suspension.
One nice thing about Kotlin Coroutines, there are libraries with basic implementations, but actually it is an language API to design suspending operations, you can use any execution model behind it, heavy threads, lightweight threads, reuse your engine loop system, it doesn't matter, it all will look like sync procedural code if you want. Or Actors, Channels, Generators.
Often people ask me why I like Kotlin Coroutines so much and dropped RxJava totally, instead of using them together, and my answer it's mostly that Rx is hard to read and reason, there's cognitive overload every time you need to read it. Doesn't matter if you know it well, you will always be thinking about the execution, while with suspending async model, I will just read the business logic line by line, as usual. I found it reeeally easier for juniors to get into, even when mixing some little reactive, overall they were faster solving problems with less async bugs.
When I meet the suspending paradigm, I learnt how much I was missing sync "old style code" and didn't know.
I agree with you, too much reactiveness may be hurtful. But I still love it for UI bindings, better yet for bidirectional bindings. I guess it's all about balance ¯_(ツ)_/¯