How are Akka actors different from Go channels?

From the question How are Akka actors different from Go channels? I have worked extensively with both Akka actors and Go channels/goroutines and would like to offer a few comments. Firstly, it is important to stress that CSP allows rendezvous-based synchronisation between goroutines using channels, and channels can optionally include buffering. When one goroutine attempts to send on an unbuffered channel, it checks whether the other party is present. If not, it sits waiting, during which it consumes no CPU and only a little memory.

Avoiding Race Conditions

At a recent conference, I had one of those 'aha!' moments when some existing pieces together to give a new insight. Sometimes, a glimpse of greater clarity sheds light on where we are and where we're going. In this particular case, I'd been wrestling with concurrency issues. All concurrent software needs to share state. Obviously, if this were not true, it would just be a bag of disjoint stuff otherwise. Sharing state is where the fun starts.

Wrestling With Concurrency - Scala Exchange 2012

I was very fortunate to join the London Scala Exchange conference over the last two days. A good range of quality talks were offered - some thought provoking, some highly entertaining. And most wrestled to some extent with concurrency. It seems that Scala is not yet at ease with itself in its concurrency model. The root of the issue is the JVM: threads are very expensive and limited to small numbers (say, 30).

Google's Go Revisited

At the end of 2009, a delightfully “little” programming language was fully released following a few years of gestation. I wrote back then about the major features of Google’s Go. Nearly two years of intensive Scala, Java and Groovy work later, I felt it was time to revisit Go with one question in mind: with so much new-found enthusiasm for non-Java languages around, what has Go got to offer that might make it stand out from the crowd?

BlockingQueues and Communicating Sequential Processes

A particularly important objective for developers producing of concurrent systems is to produce designs that always give consistent results and cannot deadlock (see The Four Horsemen on why this can be difficult). Since Java 1.5, the Java API has included the java.util.concurrent package, which contains a range of classes to support thread synchronisation, communication and safe sharing of data. This Java5 API enhancement introduced blocking queues for passing messages between threads, and with this it has been possible to write concurrent Java applications that benefit from decades of theoretical progress in how to design deadlock-free systems.