There's a discussion of why some people use Akka
here, and there's a blog post from the creator of Akka, Jonas Bonér, explaining
why Akka is a good idea. There's also a
video presentation on Akka by Jonas Bonér at the InfoQ website.
I think the argument boils down to a few key points:
Concurrency is intrinsically difficult.Concurrency with threads is really difficult.More distributed systems and multi-core processors mean we need to be able to support more concurrency.The growth of big data applications also demands more effective use of concurrency to cope with all that extra processing (you can't do everything in Hadoop).We need to make concurrency simpler in order to build robust, scalable, maintainable systems.Akka offers a way to achieve this.
Actor systems like Akka are based on asynchronous message passing and immutable state, providing a higher level of abstraction than threads, which effectively allow you as a developer to think about the actual problem you're trying to solve, without having to worry about all the details of the plumbing. I've only just started looking at Akka myself, but already it's pretty clear that Akka provides a much simpler, cleaner and more robust approach to concurrency than anything I could come up with based on threads. Of course, I'm not much of a threads programmer anyway, but then the whole point of Akka is that grunts like me don't have to be threads gurus to work productively on concurrent systems. Which sounds good to me.
But why not try it out for yourself? A good place to start is Derek Wyatt's excellent book
Akka Concurrency. Incidentally, Akka is also available for Java, although my understanding is that certain features of Akka (specifically based on Scala's support for functional programming) are not available in the Java version.
