This wasn't really possible until the addition of the Macro and enhanced reflection systems in the most recent versions of Scala. Type information isn't stable across all runtime environments. They had to come up with a way to generate proper types for distribution on the fly.
Someone correct me if I'm mischaracterizing this please. I'm only a little familiar with the new typed channels.
Akka already had typed actors, but most of the times they are useless.
The problem with actors is that they can change their interface at runtime. Very useful if you want to model state machines for example (see context.become or the FSM helpers) and it's one reason why actors are awesome.
Actors can also get their messages from multiple sources. The messages that you (the user of an actor) can send to an actor can be very different from the messages that an actor receives from other actors that it communicates with.
Akka's Actors are different from EJB's remote session beans. There is some usage overlap, as both Akka and EJB provide a way to do remote procedure calls, however there are differences in the approaches used. For me the Actor model [1] is saner.
Also, Actors aren't only about RPC. All my actors are in the same process, being a capable multi-threading model. And Akka isn't only about Actors anymore. Scala's Future/Promise interfaces were nurtured in Akka and Akka 2.2.0 includes a cool foundation for asynchronous I/O [2], being an alternative to Netty and Mina.
Actors are inherently stateful, they provide safe encapsulation coupled with patterns for persistence (see https://github.com/eligosource/eventsourced for example). Other properties are that they have addresses (ActorRef in Akka) which support location transparency, meaning that every actor which has another actor’s ActorRef can send it a message, no matter whether within the same JVM or across the network. Akka’s particular strength is that it enforces actor supervision, making your software design resilient (see http://www.infoq.com/articles/resilient-software-with-akka).
I'm very excited about Akka cluster. The company I work for plans on leveraging this in a big way. Most of our backend is already running on Akka and we've had terrific success with it so far.
