3 ms·

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 n

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.

3 ms·

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 n

by lliamander 4y ago

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.