Scala 并发模型上下文中的 Clojure 期货

Question

After being exposed to scala's Actors and Clojure's Futures, I feel like both languages have excellent support for multi core data processing.

However, I still have not been able to determine the real engineering differences between the concurrency features and pros/cons of the two models. Are these languages complimentary, or opposed in terms of their treatment of concurrent process abstractions?

Secondarily, regarding big data issues, it's not clear wether the scala community continues to support Hadoop explicitly (whereas the clojure community clearly does ). How do Scala developers interface with the hadoop ecosystem?

Answer 1

Some solutions are well solved by agents/actors and some are not. This distinction is not really about languages more than . This is a (very short) comparason of Actors/agents vs. References to try to clarify the point that the tool must fit the concurrency problem.

Actors excel in distributed situation where . If your problem can be expressed purely by passing messages then actors will do the trick. Actors work poorly where they need to modify several related data structures at the same time. The canonical example of this being moving money between bank accounts.

Clojure's ref s are a great solution to the problem of many threads needing to modify the same thing at the same time . They excel at shared memory multi-processor systems like today's PCs and Servers. In addition to the Bank account example, Rich Hickey (the author of clojure) uses the example of a baseball game to explain why this is important. If you wanted to use actors to represent a baseball game then before you moved the ball, all the fans would have to send it a message asking it where it was... and if they wanted to watch a player catching the ball things get even more complex.

Clojure has cascalog which makes writing hadoop jobs look a lot like writing clojure.

Answer 2

Actors provide a way of handling the potential interleaving and synchronization control that inevitably comes when trying to get multiple threads to work together. Each actor has a queue of messages that it processes in order one at a time so as to avoid the need to include explicit locks. In this case a Future provides a way of waiting for a response from an actor.

As far as Hadoop is concerned, Twitter just released a library specifically for Hadoop called Scalding but as long as the library is written for the JVM, it should work with either language.