And because the JVM does global stop-the-world garbage collection, which makes soft real-time implausible because of the unpredictability of GC affecting your actors. Erlang has per-process heaps.
Basically the Erlang VM was created for this use case while the JVM was not, and its not something you can just add with a library.
edit: Also the lightweightness of Erlang processes compared to Java threads[1] and hot code upgrades.
> And because the JVM does global stop-the-world garbage collection, which makes soft real-time implausible because of the unpredictability of GC affecting your actors. Erlang has per-process heaps.
Not quite. Every environment needs some shared memory semantics. In Erlang that's done with ETS tables, which don't undergo GC at all. Java's GCs are so good now, that, if shared data structures are used sparingly, would still give you better performance than BEAM. Plus, you have commercial pauseless GCs, as well as hard realtime JVMs.
> Basically the Erlang VM was created for this use case while the JVM was not, and its not something you can just add with a library. edit: Also the lightweightness of Erlang processes compared to Java threads[1] and hot code upgrades.
The JVM is so versatile, though, that all this can actually be added as a library, including true lightweight threads and hot code swapping (see Quasar[1]).
Nevertheless, BEAM was indeed designed with process isolation in mind, and on the JVM, actors might interfere with one another's execution more so than on BEAM, but even on BEAM you get the occasional full VM crashes. If total process isolation is not your main concern, you might find that Java offers more than Erlang, all things considered.
Java/Scala do allow you to do bad things. So add the following to Hershel's question:
"Assume developers are non-malicious and will only pass immutable objects across actor/future boundaries."
Also, I'm not that familiar with Erlang's memory model, so I might be wrong on this. But as far as I'm aware the memory for a message in Erlang is shared between threads - it's only local variables that use private memory. This means Erlang will also need some sort of concurrent garbage collector - does Erlang's version not stop the world, or at least the messaging subsystem?
Akka certainly does. At the company I work for all our heavy lifting is done by an Akka cluster running on EC2.
We found that the difficulty didn't lay in getting Akka to work in a clustered fashion—that was simple—but rather in architecting our backend's work distribution mechanics so as not to overload any given node. I blogged about our experience with Akka: http://blog.goconspire.com/post/64130417462/akka-at-conspire...
In principle, transitioning from multithreaded to distributed with Akka is just a matter of configuration. I've never put this to the test, but akka does make this claim.
Erlang is not just classes with a thread and a queue attached to it. Anyone can do it. It is also fault tolerance. How many of the actor libraries support creating large number of processes that have isolate heaps? How many have completely concurrent and pause-less garbage collectors?
The closer abstraction is probably OS processes + IPC. Then you get closer to the spirit of it. And Chrome browser and other software take that approach. It isolates faults. But well, you have to do a lot more work around it and those are not exactly light-weight. Erlang processes are only a few K of memory each.
The scheduler is preemptive. JVM doesn't have a preemptive scheduler so there are many situation where this is a huge plus.
Erlang's process are just threads pretending to be process which will spawn much faster than Akka.
I believe there are a few articles of Akka actor limitation versus Erlang's. I haven't delve deep into this but there are caveat with receiving message and how to handle it versus Erlang not having such caveat.
Coding in a language that isn't built with Actor/Concurrency in mind is a huge pain in the butt. Think of Javascript and Node.js and callback hells, which of course have push Javascript to adopt things such as future and etc..
Of course you can say Scala is built with concurrency in mind same with Clojure. But the underlying gears, the JVM was not compares to Erlang.
There are trade off between Erlang's VM and Java's VM. And if your requirement is a perfect match for either Erlang and Java you mind as well pick the best because coding against what the tool was intended for is just for people who enjoy pain and frustration.
The value proposition of Erlang is a great deal more than "we have actors". Actors and message passing are "symptoms" of built from the core out for fault tolerant networked multiprocessing. If you need that you should prefer Erlang.
waffle_ss|11 years ago
And because the JVM does global stop-the-world garbage collection, which makes soft real-time implausible because of the unpredictability of GC affecting your actors. Erlang has per-process heaps.
Basically the Erlang VM was created for this use case while the JVM was not, and its not something you can just add with a library.
edit: Also the lightweightness of Erlang processes compared to Java threads[1] and hot code upgrades.
[1]: http://i.imgur.com/hKMJ3HD.png
pron|11 years ago
Not quite. Every environment needs some shared memory semantics. In Erlang that's done with ETS tables, which don't undergo GC at all. Java's GCs are so good now, that, if shared data structures are used sparingly, would still give you better performance than BEAM. Plus, you have commercial pauseless GCs, as well as hard realtime JVMs.
> Basically the Erlang VM was created for this use case while the JVM was not, and its not something you can just add with a library. edit: Also the lightweightness of Erlang processes compared to Java threads[1] and hot code upgrades.
The JVM is so versatile, though, that all this can actually be added as a library, including true lightweight threads and hot code swapping (see Quasar[1]).
Nevertheless, BEAM was indeed designed with process isolation in mind, and on the JVM, actors might interfere with one another's execution more so than on BEAM, but even on BEAM you get the occasional full VM crashes. If total process isolation is not your main concern, you might find that Java offers more than Erlang, all things considered.
[1]: https://github.com/puniverse/quasar
yummyfajitas|11 years ago
"Assume developers are non-malicious and will only pass immutable objects across actor/future boundaries."
Also, I'm not that familiar with Erlang's memory model, so I might be wrong on this. But as far as I'm aware the memory for a message in Erlang is shared between threads - it's only local variables that use private memory. This means Erlang will also need some sort of concurrent garbage collector - does Erlang's version not stop the world, or at least the messaging subsystem?
eeperson|11 years ago
[1] http://oss.readytalk.com/avian/
rational-future|11 years ago
Does it? Back when I was in HFT, we were definitely running a JVM with background thread GC.
judk|11 years ago
How hard are the limits of "soft" realtime?
syjer|11 years ago
jeffdavis|11 years ago
Do any of the library actor models offer something like that?
saryant|11 years ago
We found that the difficulty didn't lay in getting Akka to work in a clustered fashion—that was simple—but rather in architecting our backend's work distribution mechanics so as not to overload any given node. I blogged about our experience with Akka: http://blog.goconspire.com/post/64130417462/akka-at-conspire...
yummyfajitas|11 years ago
CmonDev|11 years ago
rdtsc|11 years ago
The closer abstraction is probably OS processes + IPC. Then you get closer to the spirit of it. And Chrome browser and other software take that approach. It isolates faults. But well, you have to do a lot more work around it and those are not exactly light-weight. Erlang processes are only a few K of memory each.
jacquesm|11 years ago
The closer abstraction is probably more like a distributed fault tolerant OS + processes using network transparent IPC.
digitalzombie|11 years ago
Erlang's process are just threads pretending to be process which will spawn much faster than Akka.
I believe there are a few articles of Akka actor limitation versus Erlang's. I haven't delve deep into this but there are caveat with receiving message and how to handle it versus Erlang not having such caveat.
Coding in a language that isn't built with Actor/Concurrency in mind is a huge pain in the butt. Think of Javascript and Node.js and callback hells, which of course have push Javascript to adopt things such as future and etc..
Of course you can say Scala is built with concurrency in mind same with Clojure. But the underlying gears, the JVM was not compares to Erlang.
There are trade off between Erlang's VM and Java's VM. And if your requirement is a perfect match for either Erlang and Java you mind as well pick the best because coding against what the tool was intended for is just for people who enjoy pain and frustration.
njharman|11 years ago