Scala Actor

[Gudradain]

Just out of curiosity, has anyone tried to do some networking application using Scala RemoteActor?

I finally decided to try Scala. I must say that the integration with Java is flawless. You can still use everything you were using in Java and you have now access to a few more things : closure, syntax shortcut, operator overloading (kind of), actor concurrency, etc.

First impression? I love it

[sproingie]

I use Akka actors quite a bit at work, and I'm working on a new fun project that I'm trying to use Scalaz actors with, though I might give in and switch to Akka actors for that too.  The built-in actors in the scala stdlib aren't all that great.

Scala is definitely my favorite language now, though I do wish the IDE tooling weren't so awful.

[Gudradain]

I use Akka actors quite a bit at work, and I'm working on a new fun project that I'm trying to use Scalaz actors with, though I might give in and switch to Akka actors for that too.  The built-in actors in the scala stdlib aren't all that great.

Scala is definitely my favorite language now, though I do wish the IDE tooling weren't so awful.

Oh really, what is the problem with Scala actor?

One problem I noticed with Eclipse IDE is that when refactoring a mixed project Java/Scala, the refactor name in scala code won't be apply to the Java part

EDIT : Scala stdlib Actor implements the same actor as Erlang right? I thought Erlang was great in that field.

Games published by our own members! Check 'em out!

[sproingie]

The main problem with scala.actors is that they silently drop messages that aren't understood, and the implementation of that strategy means that they leak memory every time they drop a message.  They're also not quite as flexible or configurable as akka actors, and til recently they didn't have a decent Future abstraction (now it's more or less using Akka's).

Akka also has all kinds of cool extras that scala.actors doesn't have, like durable mailboxes, coordinated transactions (though not across remote actors AFAIK), agents (basically one-off actors), and supervisor hierarchies.

Scalaz actors are like the absolute barest minimum API, it's a send operator, an effect strategy, an optional error handler, and that's it.  But from that minimal base, you can construct pretty much anything else you want, as long as you're willing to dive into some hairy type theory to do it.  I'm pondering porting scalaz actors to Java, since the implementation is simple enough to do it.  Not going to bother til I have a use case for doing it in Java and not Scala though..

[Gudradain]

Yeah I found out about scala.actors memory leak while I was struggling to do my first example with actor. I implemented the Box, Producer, Consumer example from Java. Here is how the code look like :

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70   71

package scalasync import scala.actors.Actor; object Bonjour {     case object Get;   case object OK;     class Box2 extends Actor{     var isEmpty = true;     var content : Any = null;     def act(){       while(true){          if(isEmpty){             receive {             case i:Any => put(i); sender ! OK;             }          }else{            receive {              case Get => get(); sender ! OK;            }          }       }     }     def put(ref : Any){       content = ref;       isEmpty = false;       println("---Put : " + ref);     }     def get(){       println("Get : " + content);       content = null;       isEmpty = true;     }   }     class Producer(box : Box2) extends Actor{     def act(){       for(i <- 0 until 10){         println("Putting : " + i);         box ! i;         receive{           case OK => ;//Do nothing        }       }     }   }     class Consumer(box : Box2) extends Actor{     def act(){       for(i <- 0 until 10){         println("Getting : " + i);         box ! Get         receive{           case OK => ;//Do nothing        }       }     }   }     def main(args: Array[String]){     var box2 = new Box2();     var producer = new Producer(box2);     var consumer = new Consumer(box2);     box2.start();     producer.start();     consumer.start();   } }

But the strange thing is that I currently consider that sort of memory leak as wanted behavior... I mean if you look at the code, the consumer is waiting until the producer put something in the box. If the Consumer send the message first, the box will not understand it and that message will be stored and process later when the box will wait for the Get message. Is there another way to get the same behavior?

[Gudradain]

I'm pondering porting scalaz actors to Java, since the implementation is simple enough to do it.  Not going to bother til I have a use case for doing it in Java and not Scala though..

Sounds like fun

[sproingie]

Yeah, the nested receive idiom is the reason why scala.actors scans its mailbox instead of strictly queing it.  Still, there are other ways to do it that don't require a memory leak and silent dropping of mismatches, neither of which I can ever consider to be a feature (since you can always do the latter with a "case _").  Check out "become" in Akka for how you switch out receives.  In scalaz, you'd have to do something really different, probably involving a state monad or something.

1   2   3

receive {             case i:Any => put(i); sender ! OK;             }

This to me looks really wrong.  If your producer is empty and you send it a Get, it will store the Get.  Also, you should be using an Option and not null, but that's just general scala style not apropos of the actor.

[Roquen]

As an aside. I've always found it interesting (in a bad way) that so few language support a DoesNotUnderstand as that was one of the awesome features of smalltalk.

If I were to goof around with a lightweight actor framework in Java I think I'd muck around with Kilim (but I've never done a feature-set cross comparison).