The tour doesn’t touch on this.
Scala’s concurrency is often touted as one of it’s best/most distinctive features, although it isn’t part of the language, but rather implemented as an API.
While you can certainly use Java Threads in Scala, it is more customary to use the
scala.actors package. This package defines classes that interact via message-passing. If you ensure that your messages are immutable (for the most part), you will find it much easier to write concurrent code that works well.
Consider an application that takes user commands and acts on them. Some commands might take a while to complete, but you don’t necessarily want your user to have to wait until they enter the next command.
Naturally, you separate your user interface code from your processing code, and send all requests to the background, allowing the user to continue interacting with the application. This is how the web works and how Swing is supposed to work (if you are kind enough to implement your
Actions that way :). When commands are done, you want the user interface to be notified so that the user can have an idea of what’s going on.
In Java, this would be somewhat complex. The
Thread interface is very basic, so you’d need to design a “worker thread” class to handle requests and maintain a “user interface thread” to interact with the user. You’d have to provide for a way for the threads to talk. This might be via some shared structure or some shared references to one another.
Here’s the Scala version:
We see that both
Actor implementations define the method
act and that both basically loop forever around the
receive construct. This code is triggered whenever the actor in question receives a message. In the
Worker object, we do our work and send the sender of the message a response.
sender is an API call in
Actor, as is
! is used to send
sender a message.
In the first case, we send the sender the
Exit object. In the other two cases, we create a new version of
Done that indicates which command had completed (we sleep for a second when we get an
scp just to make sure things are happening concurrently).
The second class,
UserInterface, receives command strings from the caller (in the
ActorDemo object), which it sends to
Worker, and also handles the responses from
Worker, which it uses to inform the user what happened.
The output of this program might look like so:
Starting ls Starting rm -rf Starting scp ls done rm -rf done exiting… scp foo ssh://www.naildrivin5.com/home/davec/bar done
This is a contrived example, however anyone who has done Swing programming will appreciate the ease with which the work is divided and the communication is organized. This also could be very beneficial in a highly interactive web application; you might send all requests to worker actors, returning a busy indicator immediately to the user. When the worker actor completes, you can update the web application via AJAX, providing for a nice user experience. All without rolling your own message queue infrastructure.
My Thoughts on This Feature
This is the absolute extent to my interaction with this feature, however I did make an attempt to do a Java version. I didn’t get far. This was just so much easier to deal with. Part of it is Scala’s PatternMatching , but I found the actor/messaging/inbox model to be very intuitive and easy to understand.