Different Scala Actor Implementations Overview

Question

I'm trying to find the 'right' actor implementation for my thesis. I realized there is a bunch of them and it's a bit confusing to pick one. Personally I'm especially interested in remote actors, but I guess a complete overview would be helpful to many others. This is a pretty general question, so feel free to answer just for the implementation you know about.

I know about the following Scala Actor implementations (SAI). Please add the missing ones.

• Scala 2.7 (difference to)
• Scala 2.8
• Akka (http://www.akkasource.org/)
• Lift (http://liftweb.net/)

• Scalaz (http://code.google.com/p/scalaz/)

  ---

• What are the target use-cases for these SAIs (lightweight vs. "heavy" enterprise framework)?

• do they support remote actors? What shortcomings do remote actors have in the SAIs?
• How is their performace?
• How active is there community?
• How easy are they to get started? How good is the documentation?
• How easy are they to extend?
• How stable are they? Which projects are using them?
• What are their shortcomings?
• What are their design principles?
  • Are they thread based or event based (receive/ react) or both?
  • Nested receiveS
  • hotswapping the Actor’s message loop

Answer 1

As far as I know, only Scala and Akka support remote actors.

Akka is backed up by scalablesolutions, which offer commerical support and plug ins for akka. Akka seems like a heavyweight solution, which targets integration with existing frameworks (camel, AMQP, JTA, Comet, Spring, Redis) and additionally STMs and persistence.

Akka compared to Scala doesn't support nested receives, but supports hotswapping the actors message loop and has both, thread based and event based actors and so called "Event-based single-threaded" ones.

Answer 2

Scala 2.7.7. vs 2.8 after The Scala 2.8.0 RC3 distribution:

New Reactors provide more lightweight, purely event-based actors with optional, implicit sender identification. Support for actors with daemon-style semantics was added. Actors can be configured to use the efficient JSR166y fork/join pool, resulting in significant performance improvements on 1.6 JVMs. Schedulers are now pluggable and easier to customize.

There's also a design document of Haller: Scala Actors: Unifying Thread-based and Event-based Programming

Answer 3

I realized that akka enforces exhaustive matches. So even if technically receive expects a partial function, the function must not be partial. This means you have to handle every message immediately.