5 ms·

I agree. Having used reactive Java and the Elixir/OTP model of message passing, I can safely say that I'd never go back to reactive Java unless I was forced to.

by jswny 6y ago

I agree. Having used reactive Java and the Elixir/OTP model of message passing, I can safely say that I'd never go back to reactive Java unless I was forced to. It feels like you are fighting the language the whole time.

vips7L 6y ago
Hopefully Loom will be our savior.
- cutler 6y ago
  If it ever sees the light of day. How many years has it been?
  - mping 6y ago
    I have been testing the OpenJDK builds, afaik it's usable. It's still in heavy development though
lliamander 6y ago
I haven't used reactive Java, but I have used the async/await model of JS as well Erlang/OTP, and I definitely prefer message passing. The mental model is so much easier to reason about.
zmmmmm 6y ago
It's a shame because it seems to me like RxJava is eclipsing what was previously a pretty fertile ecosystem of Actor based approaches, but RxJava itself is not very nice to use compared to those which are much more natural.
- apta 6y ago
  Loom should solve all that.
  - unscaled 6y ago
    I think Loom is thrown around too haphazardly here. Loom will present an ergonomic alternative for concurrency that is strictly superior to futures, but it will not replace or significantly simplify RxJava[1]. Project Loom is also orthogonal to actors - it really doesn't dictate any specific concurrency model, it just provides fiber support in the JVM. We will definitely see actor libraries once project loom is released, but these are already available now, and they are not widely used. The only thing Loom can help them with (I hope) is better performance, but I don't think that's the reason the actor model lost ground in the Java world. [1] Project Loom can be the basis for some minor simplifications, as JetBrains did in kotlinx.coroutines.flow.
    - mping 6y ago
      I have never used Rx libraries. What are the cases where you have low friction coroutines such as loom (no "coloured" functions afaik) where you want to use RxJava? Handling backpressure? Modelling complex flows? Honest question
apta 6y ago
https://wiki.openjdk.java.net/display/loom/Main https://wiki.openjdk.java.net/display/loom/Main

by jswny 6y ago

vips7L 6y ago

Hopefully Loom will be our savior.

cutler 6y ago
If it ever sees the light of day. How many years has it been?
- mping 6y ago
  I have been testing the OpenJDK builds, afaik it's usable. It's still in heavy development though

lliamander 6y ago

I haven't used reactive Java, but I have used the async/await model of JS as well Erlang/OTP, and I definitely prefer message passing. The mental model is so much easier to reason about.

zmmmmm 6y ago

It's a shame because it seems to me like RxJava is eclipsing what was previously a pretty fertile ecosystem of Actor based approaches, but RxJava itself is not very nice to use compared to those which are much more natural.

apta 6y ago
Loom should solve all that.
- unscaled 6y ago
  I think Loom is thrown around too haphazardly here. Loom will present an ergonomic alternative for concurrency that is strictly superior to futures, but it will not replace or significantly simplify RxJava[1]. Project Loom is also orthogonal to actors - it really doesn't dictate any specific concurrency model, it just provides fiber support in the JVM. We will definitely see actor libraries once project loom is released, but these are already available now, and they are not widely used. The only thing Loom can help them with (I hope) is better performance, but I don't think that's the reason the actor model lost ground in the Java world. [1] Project Loom can be the basis for some minor simplifications, as JetBrains did in kotlinx.coroutines.flow.
  - mping 6y ago
    I have never used Rx libraries. What are the cases where you have low friction coroutines such as loom (no "coloured" functions afaik) where you want to use RxJava? Handling backpressure? Modelling complex flows? Honest question

apta 6y ago

https://wiki.openjdk.java.net/display/loom/Main https://wiki.openjdk.java.net/display/loom/Main