Scala 並發模型上下文中的 Clojure 期貨

Question

接觸了scala的Actors和Clojure的Futures之后，感覺這兩種語言對多核數據處理的支持都非常好。

但是，我仍然無法確定兩種模型的並發特性和優缺點之間的真正工程差異。 這些語言在處理並發過程抽象方面是互補的還是相反的？

其次，關於大數據問題，scala 社區是否繼續明確支持 Hadoop 尚不清楚（而 clojure 社區顯然支持）。 Scala 開發人員如何與 hadoop 生態系統交互？

Answer 1

代理/參與者可以很好地解決一些解決方案，而有些則沒有。 這種區別實際上並不是關於語言，而是關於特定問題如何適合一般解決方案類別。 這是 Actors/agents 與 References 的（非常簡短的）比較，試圖闡明該工具必須適合並發問題的觀點。

Actors 在不需要同時修改數據的分布式情況下表現出色。 如果您的問題可以純粹通過傳遞消息來表達，那么演員就可以解決問題。 Actor 在需要同時修改多個相關數據結構的情況下效果不佳。 典型的例子是在銀行賬戶之間轉移資金。

Clojure 的ref很好的解決了很多線程需要同時修改同一個東西的問題。 他們擅長共享內存多處理器系統，如當今的 PC 和服務器。 除了銀行帳戶示例之外，Rich Hickey（clojure 的作者）還使用棒球比賽的示例來解釋為什么這很重要。 如果你想用演員來代表一場棒球比賽，那么在你移動球之前，所有的球迷都必須向它發送一條消息，詢問它在哪里……如果他們想看一個球員接球，事情就會變得平分秋色更復雜。

Clojure 有 cascalog，這使得編寫 hadoop 作業看起來很像編寫 clojure。

Answer 2

Actors 提供了一種處理潛在的交織和同步控制的方法，當試圖讓多個線程一起工作時不可避免地會出現這種情況。 每個參與者都有一個消息隊列，它一次一個地處理這些消息，以避免需要包含顯式鎖。 在這種情況下， Future 提供了一種等待參與者響應的方法。

就 Hadoop 而言，Twitter 剛剛發布了一個專門用於 Hadoop 的庫，稱為Scalding，但只要該庫是為 JVM 編寫的，它就應該適用於任何一種語言。