Hacker News new | ask | show | jobs
by pron 3972 days ago
> Actor model does not require concurrent data structure to be effective. Actually that's the whole point of it...

That's complicated. Actors don't require concurrent data structures for the bits that don't require concurrent data structures but they do for the bits that do :) That's why Erlang has ETS. That's why you still need a database.
1 comments
nickpsecurity 3972 days ago
No it's not. The proper way to design systems is breaking them into pieces, implementing each one the best way for that piece, and connecting them together. So, if one can't do DB's with Actors, do it with another tool or model (eg Eiffel/Java w/ SCOOP). Use Erlang/BEAM for what it's good at. There's also tools such as ZeroMQ that make the integration fast & easier. You get the best of both worlds.
link
pron 3972 days ago
All the more reason to use Erlang/JVM alongside other JVM languages. Polyglotism is one of the JVM's greatest strengths, and interlanguage interoperability on the JVM is the best you can get.

And Erlang/JVM can be even better than Erlang/BEAM at everything Erlang/BEAM is good at. There is nothing in BEAM that makes it more appropriate for running Erlang than HotSpot (that may have been true in the past, but that's no longer the case). BEAM's Erlang specialty simply means its development required relatively little effort to run Erlang reasonably well. It doesn't mean the JVM can't run Erlang better, and at this point in time we have every reason to believe it can run Erlang much better than BEAM.

link
nickpsecurity 3971 days ago
"Polyglotism is one of the JVM's greatest strengths, and interlanguage interoperability on the JVM is the best you can get."

It's not the best you can get but polyglot support is a strength.

"There is nothing in BEAM that makes it more appropriate for running Erlang than HotSpot (that may have been true in the past, but that's no longer the case)."

Still got it beat on latency and security risk per dollar spent: zero for Erlang w/ 5 digits for RT-JVM. If these aren't an issue, then Erlang on JVM may indeed be a superior option. I can imagine many use cases where it would be.

link
pron 3969 days ago
> zero for Erlang w/ 5 digits for RT-JVM

RT-JVM's guarantee scheduling latencies of 2us. Erlang doesn't come close. In practice, stock HotSpot has better latency than Erlang. Erlang's "guarantees" are only in effect when 1) no native code is used, 2) no global effects are used (some process registrations, binary heap, etc.).

link