4 ms·

The argument seems to be that the actor model implementations on the JVM aren't all that fast and the language can't stop you from shooting yourself in the foot

The argument seems to be that the actor model implementations on the JVM aren't all that fast and the language can't stop you from shooting yourself in the foot. That's not really the issue as far as I'm concerned. Message-passing concurrency actually allows people be productive writing concurrent code that has a hope of working -- that is the main advantage. Occasionally things go wrong. Occasionally you need more performance and have to drop down to a lower level. But I can easily write a web service running on the JVM that gets 1000 requests/s per CPU with a bit of message passing concurrency. That's the point. Heck, I don't even like the actor model -- I much prefer CSP -- but I'd attack it for other reasons (like lack of type safety).

MCRed 12y ago
Right, and when you "drop down to a lower level" to get more performance, the entire house of cards comes crashing down with bugs that are extremely difficult to debug. The issue isn't actor model on a virtual machine-- erlang runs on a VM-- the issue is that the actor model is insufficient. You need pretty much most of OTP to build reliable, stable, concurrent systems. This is why goroutines, everything on the JVM, etc are not going to work. The sad thing is, I think the primary reason people are not using Erlang is they are afraid of the syntax, but even that reason is obliterated by the existence of Elixir (an even better language on the erlang VM)
- gilbertw1 12y ago
  What do you mean by: "This is why goroutines, everything on the JVM, etc are not going to work." I've used Akka very successfully on the JVM for non-trivial clustered applications where performance is important, and I'm pretty sure the existence of most of google's infrastructure says that goroutines work at least a little bit. Do you mean not work well? They won't gain traction?
  - jeremyjh 12y ago
    For example, Go has no means of monitoring or linking to it's goroutines; without supervision trees the Erlang model for resiliency cannot be implemented.
yummyfajitas 12y ago
The lack of type safety is not really a flaw with the actor model. It is a flaw in the Any => Unit implementation of actors currently being heavily promoted by Typesafe, Inc (irony abounds). A while back I wrote a type-safe variant of actors (I called them Agents). It's done on top of scalaz-streaming which also gives better performance than akka (e.g., x.map(f).map(g) doesn't involve 2 trips back to the threadpool). http://www.chrisstucchio.com/blog/2014/agents.html http://www.chrisstucchio.com/blog/2014/agents.html Another neat benefit is separating state changes from effects. E.g., if you have a IncrementCounterAndUpdateRedis agent, you can test it's counter incrementing functionality without ever touching redis.

MCRed 12y ago

Right, and when you "drop down to a lower level" to get more performance, the entire house of cards comes crashing down with bugs that are extremely difficult to debug. The issue isn't actor model on a virtual machine-- erlang runs on a VM-- the issue is that the actor model is insufficient. You need pretty much most of OTP to build reliable, stable, concurrent systems. This is why goroutines, everything on the JVM, etc are not going to work. The sad thing is, I think the primary reason people are not using Erlang is they are afraid of the syntax, but even that reason is obliterated by the existence of Elixir (an even better language on the erlang VM)

gilbertw1 12y ago
What do you mean by: "This is why goroutines, everything on the JVM, etc are not going to work." I've used Akka very successfully on the JVM for non-trivial clustered applications where performance is important, and I'm pretty sure the existence of most of google's infrastructure says that goroutines work at least a little bit. Do you mean not work well? They won't gain traction?
- jeremyjh 12y ago
  For example, Go has no means of monitoring or linking to it's goroutines; without supervision trees the Erlang model for resiliency cannot be implemented.

yummyfajitas 12y ago

The lack of type safety is not really a flaw with the actor model. It is a flaw in the Any => Unit implementation of actors currently being heavily promoted by Typesafe, Inc (irony abounds). A while back I wrote a type-safe variant of actors (I called them Agents). It's done on top of scalaz-streaming which also gives better performance than akka (e.g., x.map(f).map(g) doesn't involve 2 trips back to the threadpool). http://www.chrisstucchio.com/blog/2014/agents.html http://www.chrisstucchio.com/blog/2014/agents.html Another neat benefit is separating state changes from effects. E.g., if you have a IncrementCounterAndUpdateRedis agent, you can test it's counter incrementing functionality without ever touching redis.