Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This answer isn't really mine. <a href="http://doc.akka.io/docs/misc/Comparison_between_4_actor_frameworks.pdf" rel="noreferrer">It was produced</a> by Viktor Klang (of Akka fame) with the help of David Pollak (of Lift fame), Jason Zaugg (of Scalaz fame), Philipp Haller (of Scala Actors fame).</p> <p>All I'm doing here is formatting it (which would be easier if Stack Overflow supported tables).</p> <p>There are a few places I'll fill later when I have more time.</p> <h2>Design Philosophy</h2> <ul> <li><p>Scalaz Actors</p> <p>Minimal complexity. Maximal generality, modularity and extensibility. </p></li> <li><p>Lift Actors</p> <p>Minimal complexity, Garbage Collection by JVM rather than worrying about an explicit lifecycle, error handling behavior consistent with other Scala &amp; Java programs, lightweight/small memory footprint, mailbox, statically similar to Scala Actors and Erlang actors, high performance.</p></li> <li><p>Scala Actors</p> <p>Provide the full Erlang actor model in Scala, lightweight/small memory footprint. </p></li> <li><p>Akka Actors</p> <p>Simple and transparently distributable, high performance, lightweight and highly adaptable.</p></li> </ul> <h2>Versioning</h2> <pre> Scalaz Actors Lift Actors Scala Actors Akka Actors Current stable ver. 5 2.1 2.9.0 0.10 Minimum Scala ver. 2.8 2.7.7 2.8 Minimum Java ver. 1.5 1.5 1.6 </pre> <h2>Actor Model Support</h2> <pre> Scalaz Actors Lift Actors Scala Actors Akka Actors Spawn new actors Yes Yes Yes Yes inside of actor Send messages to Yes Yes Yes Yes known actor Change behavior Actors are Yes Yes: nested Yes: for next message immutable react/receive become/unbecome Supervision Not provided No Actor: Yes, Yes (link/trapExit) Reactor: No </pre> <h2>Level of state isolation</h2> <p>If user defines public methods on their Actors, are they callable from the outside?</p> <ul> <li>Scalaz Actors: n/a. Actor is a sealed trait.</li> <li>Lift Actors: Yes</li> <li>Scala Actors: Yes</li> <li>Akka Actors: No, actor instance is shielded behind an ActorRef.</li> </ul> <h2>Actor type</h2> <ul> <li>Scalaz Actors: <code>Actor[A] extends A =&gt; ()</code></li> <li>Lift Actors: <code>LiftActor</code>, <code>SpecializeLiftActor[T]</code></li> <li>Scala Actors: <code>Reactor[T]</code>, <code>Actor extends Reactor[Any]</code></li> <li>Akka Actors: <code>Actor[Any]</code></li> </ul> <h2>Actor lifecycle management</h2> <pre> Scalaz Actors Lift Actors Scala Actors Akka Actors Manual start No No Yes Yes Manual stop No No No Yes Restart-on-failure n/a Yes Yes Configurable per actor instance Restart semantics n/a Rerun actor Restore actor to stable state by re-allocating it and behavior throw away the old instance Restart configurability n/a n/a X times, X times within Y time Lifecycle hooks provided No lifecycle act preStart, postStop, preRestart, postRestart </pre> <h2>Message send modes</h2> <pre> Scalaz Actors Lift Actors Scala Actors Akka Actors Fire-forget a ! message actor ! msg actor ! msg actorRef ! msg a(message) Send-receive-reply (see 1) actor !? msg actor !? msg actorRef !! msg actor !! msg Send-receive-future (see 2) actor !! msg actorRef !!! msg Send-result-of- promise(message). future.onComplete( f => to ! f.result ) future to(actor) Compose actor with actor comap f No No No function (see 3) </pre> <p>(1) Any function f becomes such an actor: </p> <pre><code>val a: Msg =&gt; Promise[Rep] = f.promise val reply: Rep = a(msg).get </code></pre> <p>(2) Any function f becomes such an actor:</p> <pre><code>val a = f.promise val replyFuture = a(message) </code></pre> <p>(3) Contravariant functor: <code>actor comap f</code>. Also Kleisli composition in <code>Promise</code>.</p> <h2>Message reply modes</h2> <p>TBD</p> <pre> Scalaz Actors Lift Actors Scala Actors Akka Actors reply-to-sender-in-message reply-to-message </pre> <h2>Message processing</h2> <p>Supports nested receives?</p> <ul> <li>Scalaz Actors: --</li> <li>Lift Actors: Yes (with a little hand coding).</li> <li>Scala Actors: Yes, both thread-based receive and event-based react.</li> <li>Akka Actors: No, nesting receives can lead to memory leaks and degraded performance over time.</li> </ul> <h2>Message Execution Mechanism</h2> <p>TBD</p> <pre> Scalaz Actors Lift Actors Scala Actors Akka Actors Name for Execution Mechanism Execution Mechanism is configurable Execution Mechanism can be specified on a per-actor basis Lifecycle of Execution Mechanism must be explicitly managed Thread-per-actor execution mechanism Event-driven execution mechanism Mailbox type Supports transient mailboxes Supports persistent mailboxes </pre> <h2>Distribution/Remote Actors</h2> <pre> Scalaz Actors Lift Actors Scala Actors Akka Actors Transparent remote n/a No Yes Yes actors Transport protocol n/a n/a Java Akka Remote Protocol serialization (Protobuf on top of TCP) on top of TCP Dynamic clustering n/a n/a n/a In commercial offering </pre> <h2>Howtos</h2> <p>TBD</p> <pre> Scalaz Actors Lift Actors Scala Actors Akka Actors Define an actor Create an actor instance Start an actor instance Stop an actor instance </pre>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload