Modern Concurrency: Erlang, Scala, Go, Clojure

kachayev.github.com

7 pointskachayev2 comments

This presentation is right in line with something I've been thinking about lately. Is programming with Clojure agents (and atoms/STM) functionally equivalent to programming with Actors or Go routines with Go channels? In other words, can you solve all the same problems?

One difference, I imagine, is that the Actor model is distributable (a la Erlang and recent Akka editions), whereas the Clojure model is fundamentally about safely sharing memory in the same process space.

Beyond that though, is there an example of a problem that is hard to do with STM or the Clojure model but relatively straightforward with Actors or Go channels? And then the same question in the other direction.

I'd be very interested in studying such an example!

To answer the question when STM is hard to use, you can imaging any case of simulation. Few years ago I worked with engine for real-time brokers trading simulations: thousands of independent players accept different information streams and make deals. Each deal is several steps of negotiations with two-phase commit. Plus different monitoring tools, timers, generators and randomizers.. Whole system was written in Erlang, and you know... two-phase commit is really hard to implement in right way without potential deadlocks and other problems. But it's looks good and "natural" (as to say) in Actors language. I used to try to do something like this with STM and I quickly gave up with mess of unreadable code.

Reply on news.ycombinator.com