Actors in Scala vs. Scalaz vs. Akka

You forgot Lift actors!
Here's the summary as I understand it, this might be a good one for stackoverflow...
Built in actors:- Widely used and documented, good community support - support nested receive/react out of the box- had a memory leak (now fixed) in older versions
Lift Actors:- don't support nested receive/react out of the box, but the alternative is not too painful - share a common interface with Akka- widely used and supported via the lift group
Akka actors:- don't support nested receive/react out of the box, but the alternative is not too painful - have very good remote actor capabilities- have supervisor hierarchies- can also be used from Java, which is convenient for anyone undergoing a Java->Scala migration- share a common interface with Lift actors
Scalaz actors- have a general problem of being under-documented- scalaz does tend towards elegance (and also VERY advanced theory in places)


I'm sure there's more :)

2010/1/8 Kai Meder <stuff@kai.meder.info>

Hello

are there any notes on the various Actor-Implementations?

The Scalaz-Version looks awesome short and elegant, the Akka one
supports Transactors and Scala's own Actor is widely used.
Are there severe differences in basic Actor-funtionality between them?

Thanks, Kai

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Akka supports:
Transactional actors via STM
Persistent actor state via distributed storage (cassandra, mongoDB, redis)
OTP style supervisors
Excellent support for remote actors and dynamic clustering
+ a lot more

akkasource.org

On Jan 8, 2010 4:47 PM, "Kevin Wright" <kev.lee.wright@googlemail.com> wrote:

You forgot Lift actors!
Here's the summary as I understand it, this might be a good one for stackoverflow...
Built in actors:- Widely used and documented, good community support - support nested receive/react out of the box- had a memory leak (now fixed) in older versions
Lift Actors:- don't support nested receive/react out of the box, but the alternative is not too painful - share a common interface with Akka- widely used and supported via the lift group
Akka actors:- don't support nested receive/react out of the box, but the alternative is not too painful - have very good remote actor capabilities- have supervisor hierarchies- can also be used from Java, which is convenient for anyone undergoing a Java->Scala migration- share a common interface with Lift actors
Scalaz actors- have a general problem of being under-documented- scalaz does tend towards elegance (and also VERY advanced theory in places)


I'm sure there's more :)

2010/1/8 Kai Meder <stuff@kai.meder.info>

> > Hello > > are there any notes on the various Actor-Implementations? > > The Scalaz-Version look...

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

> Scalaz actors
> - have a general problem of being under-documented
> - scalaz does tend towards elegance (and also VERY advanced theory in
> places)

Indeed, I'm really waiting for an Introduction...

It's probably worth saying that nested receive/react is thought by some to
be an anti-pattern, and that the alternative of modeling protocols as
explicit finite state machines is usually better design. This makes the
fact that the Scala actors support nested receive/react less of a win than
this list might imagine.

That reminds me of another interesting thing you can do with receive.  You don't have to be explicitly in an actor to use it.  So you can do:
import scala.actors.Actor._anActor ! 'message receive {  case 'goodReply => println("yes!")  case 'badReply => println("no!")}


On Sat, Jan 9, 2010 at 12:44 PM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

It's probably worth saying that nested receive/react is thought by some to
be an anti-pattern, and that the alternative of modeling protocols as
explicit finite state machines is usually better design.  This makes the
fact that the Scala actors support nested receive/react less of a win than
this list might imagine.

--
View this message in context: http://old.nabble.com/-scala--Actors-in-Scala-vs.-Scalaz-vs.-Akka-tp27077792p27090979.html
Sent from the Scala mailing list archive at Nabble.com.

--
http://erikengbrecht.blogspot.com/

Yay for creating magic thread-local actors on demand!!!!!!!

BTW -> This is the reason (AFAICT) that you *need* a seperate GC for the Scala actors library.


In terms of Scalaz actors, the design is very simple and elegant.  It has all the reconfigurability of the other actors libraries, but the all "out of the box" functionality might not have been written yet.

Scalaz actors have 3 customization points

1)

err : Throwable => Unit
 
This is your method of handling errors.  If you wish to link actors and have supervisor hierarchies provide a function like:  { err : Throwable => supervisor ! (actor, err) }



2)
c: A => Unit

This is your message handling routine.  Just make it be a partial function, and you'r ready to get messages.   { case Foo() => handleFoo() } where the Foo() pattern is matchable on A (we need a symbol for that.... Foo p: A ?)


Note: that's it's *typed by default*.  That's a big wio for using sealed trait hierarchies with your message API.

3)
s : Strategy[Unit]

This is your mechanism of hooking into the scheduler of the actors.  scalaz.concurrent.strategy has a few of these implemented.


Here's an example "swing" strategy for executing message handling as part of the normal AWTEventQueue processing (i.e. in the AWT thread). Note: I'm copying this code from memory, so I may have messed it up, also it's not the most robust implementation).


package scalaz.concurrent.strategy

object Swing {
   //This class exists solely to convert a Runnable to a Future for the older EventQueue interfaces that only has "invokeLater" and "invokeAndWait" for tasks.

   private[this] class Future[A](f : () => A) extends Runnable {
       private var result : Option[A] = None
       override def run() : Unit = {
          val r = f()
          synchronized {
             done = Some(r)

             notify()
          }
       }

       def get : A = {
           synchronized {
              while(!done.isDefined) {
                 wait()
              }
              done.get

           }
       }
   }
   implicit def strategy[A] = new Strategy[A] {
     def apply(a : () => A) = {
       val future = new Future(a)
       _root_.javax.swing.SwingUtilities.invokeLater(future)

       () => future.get
     }
   }
}


Anyway, I hope that helps you get started if you're interested in scalaz.  I'd love to see someone take the base framework and start adding helper things like supervisor hierarchies (e.g. "restart all on failure", etc.) but in the standard scalaz elegant way.


- Josh

On Sat, Jan 9, 2010 at 1:04 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

That reminds me of another interesting thing you can do with receive.  You don't have to be explicitly in an actor to use it.  So you can do:
import scala.actors.Actor._anActor ! 'message receive {  case 'goodReply => println("yes!")  case 'badReply => println("no!")}


On Sat, Jan 9, 2010 at 12:44 PM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

It's probably worth saying that nested receive/react is thought by some to
be an anti-pattern, and that the alternative of modeling protocols as
explicit finite state machines is usually better design.  This makes the
fact that the Scala actors support nested receive/react less of a win than
this list might imagine.

--
View this message in context: http://old.nabble.com/-scala--Actors-in-Scala-vs.-Scalaz-vs.-Akka-tp27077792p27090979.html
Sent from the Scala mailing list archive at Nabble.com.

--
http://erikengbrecht.blogspot.com/

I added two Swing execution strategies to Scalaz trunk:

http://code.google.com/p/scalaz/source/browse/trunk/core/src/main/scala/scalaz/concurrent/strategy/SwingStrategy.scala

-jason

On Sat, Jan 9, 2010 at 7:45 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Here's an example "swing" strategy for executing message handling as part of the normal AWTEventQueue processing (i.e. in the AWT thread). Note: I'm copying this code from memory, so I may have messed it up, also it's not the most robust implementation).

I am interested in Scalaz. It appears to be chock-full of goodies, but it seems to be hard to crack for run-of-the-mill ex-Java programmers like myself without a firm grounding in category theory or experience with purely functional languages. The Google Code site appears to be devoid of documentation (Not that there is anything wrong with that... :). Is there a recommended path of approach for would-be learners? Something like a collection of "Hey, you can do this: ..., isn't that neat?" examples, for instance, would be great. Sorry if I am missing something obvious.

Andreas

Scalaz 5 is in development, targeted at Scala 2.8. It is relatively complete, so if you're feeling adventurous, start here.

Tony has recently started work on a user guide. But for now, you could start by looking through some of the examples (in the sources here: http://code.google.com/p/scalaz/source/browse/trunk/example/src/main/scala/scalaz/)

A lot of the concepts are taken from Haskell, so you can learn a lot from the Haskell Wiki. It helps to have a solid understanding of implicits (views and parameters) in the Scala language, as these glue things together in the Scalaz implementation. Be prepared to carefully read type signatures, these will tell you more than the Scaladoc (especially when none is provided).

Please feel free to direct questions of any level to the Scalaz Google Group.

-jason

On Fri, Jan 15, 2010 at 3:51 PM, Windemuth Andreas <windemut@yahoo.com> wrote:

I am interested in Scalaz. It appears to be chock-full of goodies, but it seems to be hard to crack for run-of-the-mill ex-Java programmers like myself without a firm grounding in category theory or experience with purely functional languages. The Google Code site appears to be devoid of documentation (Not that there is anything wrong with that... :). Is there a recommended path of approach for would-be learners? Something like a collection of "Hey, you can do this: ..., isn't that neat?" examples, for instance, would be great. Sorry if I am missing something obvious.

Andreas

Hi Andreas

If you are interested in Scalaz I would strongly suggest to
be somewhat acquainted with Haskell first.

Haskell is much more friendly (power of type inference,
do notation syntax, etc. etc...) to learn pure functional
programming concepts that are at the core of Scalaz.

It would be a very refreshing experience by itself and provide
a completely different approach to programming.

Paolo

Windemuth Andreas wrote:
>
> I am interested in Scalaz. It appears to be chock-full of goodies, but
> it seems to be hard to crack for run-of-the-mill ex-Java programmers
> like myself without a firm grounding in category theory or experience
> with purely functional languages. The Google Code site appears to be
> devoid of documentation (Not that there is anything wrong with that...
> :). Is there a recommended path of approach for would-be learners?
> Something like a collection of "Hey, you can do this: ..., isn't that
> neat?" examples, for instance, would be great. Sorry if I am missing
> something obvious.
>
> Andreas
>
>

I hope to not reference Haskell in the aforementioned user guide.

While I have started on such a guide, I am also pursuing a rather
detailed health complaint with the government and they have just
requested (even more!) documentation, which is sure to suck up all my
time in the near future.

Paolo Losi wrote:
> Hi Andreas
>
> If you are interested in Scalaz I would strongly suggest to
> be somewhat acquainted with Haskell first.
>
> Haskell is much more friendly (power of type inference,
> do notation syntax, etc. etc...) to learn pure functional
> programming concepts that are at the core of Scalaz.
>
> It would be a very refreshing experience by itself and provide
> a completely different approach to programming.
>
> Paolo
>
> Windemuth Andreas wrote:
>>
>> I am interested in Scalaz. It appears to be chock-full of goodies,
>> but it seems to be hard to crack for run-of-the-mill ex-Java
>> programmers like myself without a firm grounding in category theory
>> or experience with purely functional languages. The Google Code site
>> appears to be devoid of documentation (Not that there is anything
>> wrong with that... :). Is there a recommended path of approach for
>> would-be learners? Something like a collection of "Hey, you can do
>> this: ..., isn't that neat?" examples, for instance, would be great.
>> Sorry if I am missing something obvious.
>>
>> Andreas
>>
>>
>
>

Windemuth Andreas wrote:
> I am interested in Scalaz. It appears to be chock-full of goodies, but it seems to be hard to crack for run-of-the-mill ex-Java programmers like myself without a firm grounding in category theory or experience with purely functional languages. The Google Code site appears to be devoid of documentation (Not that there is anything wrong with that... :). Is there a recommended path of approach for would-be learners? Something like a collection of "Hey, you can do this: ..., isn't that neat?" examples, for instance, would be great. Sorry if I am missing something obvious.
>
> Andreas
>
>
>
>
There are some examples
http://code.google.com/p/scalaz/source/browse/continuous/#continuous/201...

They compile and run against trunk.

Tony, Paolo, Jason,

Thanks for the tips. It seems the best route is to study Haskell first, if you have the time. I'll see what I can do...

I'd definitely be interested in that guide of Tony's.

Andreas