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

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.

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)

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?

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.