Among the main attractions of the Scala language is that it supports the Actor-based model of concurrency. Actors are not part of the Scala language per se, but a full-featured Actors library is included in the standard Scala API. Because the Scala language allows one to implement an API that, for all practical purposes, looks like an embedded DSL, the standard Scala Actors library is very easy and natural to use from any Scala code.
In the past year, several additional Actors libraries have sprung up as well in the Scala community. The best-known example is the Lift framework's own Actors implementation. As a Web framework, Lift had some special requirements that were difficult to satisfy with the standard Scala Actors library. Thus, the Lift project supplied its own, special-purpose "Lift Actors." Erik Engbrecht and Jonas Boner have also been independently developing Actors implementations.
Writing a basic actor implementation is actually pretty trivial, especially given java.util.concurrent classes that provide a decent chunk of the functionality in Scala actors, all for free on JDK5+. So this begs the question few questions:
Why is the standard Scala actor implementation so complex when others have done it in a such simpler fashion?
Is it better to have one, big actor library that supports a wide variety of use cases, or a bunch of smaller ones targeted at specific niches and programming styles?
If there are to be a bunch, should they just be conceptually similar (e.g. all based on the actor model), or should there be interoperability among them?
In the rest of his blog post, Engbrecht compares some features of the standard Scala Actors with those of Lift Actors, and highlights where specialized Actor implementations may trade off expressivity for ease of use in special use-cases.
What do you think: Should the Scala Actors library evolve to be more customizable, or expressive, or do you foresee the proliferation of special-purpose Actor libraries?
Previous Topic
