5 ms·

With Loom incoming, Go's only unfair advantage (shared with Erlang) may be gone soon. I guess we'll have the answer in a few years. Will the next WhatsApp be w

With Loom incoming, Go's only unfair advantage (shared with Erlang) may be gone soon. I guess we'll have the answer in a few years. Will the next WhatsApp be written in Java?

haspok 4y ago
Loom does a small fraction of what the Erlang VM is capable of doing. For one, the Erlang VM has built-in preemptive green thread scheduling, which means it can suspend your green thread at ANY instruction, not just when an IO call is in progress. Loom is a step in the right direction, but Erlang is in its own universe for what it was designed for.
- BenoitP 4y ago
  > which means it can suspend your green thread at ANY instruction True. Out of curiosity: what's the use case for this? Surely side-effects-out-of-your-system is enough?
  - notamy 4y ago
    > True. Out of curiosity: what's the use case for this? Scheduling is deterministic, which is a VERY useful property to have. See ex. http://erlang.org/pipermail/erlang-questions/2006-December/024588.html http://erlang.org/pipermail/erlang-questions/2006-December/0... about changing scheduler determinism.
    - marwis 4y ago
      The thread you linked is about the benefits of inducing scheduling non-determinism.
- slekker 4y ago
  Is Loom THAT big of a deal? Can you point me towards some references of why this is the case?
  - SureshG 4y ago
    Yes, IMO game changing for java. Read this JEP - https://openjdk.org/jeps/425 https://openjdk.org/jeps/425 Here is a simple echo server running on Virtual thread (using same old blocking APIs, handle 5m persistent connections) - https://github.com/ebarlas/project-loom-c5m/blob/main/src/main/java/loomtest/EchoServer.java#L24 https://github.com/ebarlas/project-loom-c5m/blob/main/src/ma...
- throwawaymaths 4y ago
  Erlang still has failure domains as a first class concept which neither go or Java are likely to have ever.
lliamander 4y ago
It will take more than green threads to be equivalent to Erlang. Erlang's concurrency model depends upon a completely non-shared memory model, which Java will never have. Edit: and programming it in Java will always be more laborious than in Erlang. Sure, you could put Erlang on the JVM (as the Loom folks want to do) but then is Java really the winner here, or did Oracle just make an alternative BEAM?
- BenoitP 4y ago
  Surely having a shared memory model increases the design space? Or is this about memory management performance? A benchmark should settle things in that case. Maybe it will be a draw! Erlang's almost-no-op deallocation vs Java's world-class JIT. Some applications are bound to be better suited to one specific side. I guess we'll see; but it cannot be denied that with Loom Java started to compete on a non-void part of Erlang's land.
  - cogman10 4y ago
    It's certainly a trade off. One thing erlang can do which java cannot is survive one of it's actors OOMEing. That kills the actor and not the VM. That comes at some extreme costs and implications to what the VM is capable of achieving, but it is something that's pretty impressive.
  - lliamander 4y ago
    Absolutely. And I'm not particularly partisan in this: I like Erlang ( the language in general as well as the concurrency model) and if Java moves closer to that then all the better.
- wewtyflakes 4y ago
  While interesting, I'm not sure how that will translate into practice. How easy is it to hire up an organization of Erlang developers, versus, Java developers? I suspect Java's features as compared to Erlang will be good enough, that the specific use-cases enabled by knowledgeable Erlang developers will be non-competitive in the general developer labor market, but I am open to being wrong/educated.

With Loom incoming, Go's only unfair advantage (shared with Erlang) may be gone soon. I guess we'll have the answer in a few years. Will the next WhatsApp be written in Java?

haspok 4y ago

Loom does a small fraction of what the Erlang VM is capable of doing. For one, the Erlang VM has built-in preemptive green thread scheduling, which means it can suspend your green thread at ANY instruction, not just when an IO call is in progress. Loom is a step in the right direction, but Erlang is in its own universe for what it was designed for.

BenoitP 4y ago
> which means it can suspend your green thread at ANY instruction True. Out of curiosity: what's the use case for this? Surely side-effects-out-of-your-system is enough?
- notamy 4y ago
  > True. Out of curiosity: what's the use case for this? Scheduling is deterministic, which is a VERY useful property to have. See ex. http://erlang.org/pipermail/erlang-questions/2006-December/024588.html http://erlang.org/pipermail/erlang-questions/2006-December/0... about changing scheduler determinism.
  - marwis 4y ago
    The thread you linked is about the benefits of inducing scheduling non-determinism.
slekker 4y ago
Is Loom THAT big of a deal? Can you point me towards some references of why this is the case?
- SureshG 4y ago
  Yes, IMO game changing for java. Read this JEP - https://openjdk.org/jeps/425 https://openjdk.org/jeps/425 Here is a simple echo server running on Virtual thread (using same old blocking APIs, handle 5m persistent connections) - https://github.com/ebarlas/project-loom-c5m/blob/main/src/main/java/loomtest/EchoServer.java#L24 https://github.com/ebarlas/project-loom-c5m/blob/main/src/ma...
throwawaymaths 4y ago
Erlang still has failure domains as a first class concept which neither go or Java are likely to have ever.

lliamander 4y ago

It will take more than green threads to be equivalent to Erlang. Erlang's concurrency model depends upon a completely non-shared memory model, which Java will never have. Edit: and programming it in Java will always be more laborious than in Erlang. Sure, you could put Erlang on the JVM (as the Loom folks want to do) but then is Java really the winner here, or did Oracle just make an alternative BEAM?

BenoitP 4y ago
Surely having a shared memory model increases the design space? Or is this about memory management performance? A benchmark should settle things in that case. Maybe it will be a draw! Erlang's almost-no-op deallocation vs Java's world-class JIT. Some applications are bound to be better suited to one specific side. I guess we'll see; but it cannot be denied that with Loom Java started to compete on a non-void part of Erlang's land.
- cogman10 4y ago
  It's certainly a trade off. One thing erlang can do which java cannot is survive one of it's actors OOMEing. That kills the actor and not the VM. That comes at some extreme costs and implications to what the VM is capable of achieving, but it is something that's pretty impressive.
- lliamander 4y ago
  Absolutely. And I'm not particularly partisan in this: I like Erlang ( the language in general as well as the concurrency model) and if Java moves closer to that then all the better.
wewtyflakes 4y ago
While interesting, I'm not sure how that will translate into practice. How easy is it to hire up an organization of Erlang developers, versus, Java developers? I suspect Java's features as compared to Erlang will be good enough, that the specific use-cases enabled by knowledgeable Erlang developers will be non-competitive in the general developer labor market, but I am open to being wrong/educated.