4 ms·

Judging from ... > Actors also introduce some overhead in case you just want to read a single variable from a datastructure safely. ... I think the large part

Judging from ... > Actors also introduce some overhead in case you just want to read a single variable from a datastructure safely. ... I think the large part which you are missing is that in Scala, everything is a library, there are no “privileged” operations or data structures: In Scala, you have a huge set of options available which can be used where appropriate. There was a talk by the creators of Akka recently, and the most important message of their talk was “pick your poison”. It's not like in Go where people claim that channels and “goroutines” are the solution to every problem or how the Clojure community treats STM/Agents. In a sense, this also shows the maturity of Scala's developers and ecosystem, because they don't claim that X or Y is the ultimate solution to everything. - Scala has a full range of immutable & persistent as well as mutable & concurrent data structures available. In general, they are faster and more efficient than the ones in Clojure, due to the heavy tuning they received and the fact that you can pick the implementation which has the best performance characteristics for your use-case. - The collection library supports data-parallel operations since 2.9, but I think it's great that Clojure tries to catch up! - Additionally, Scala offers a standardized Future&Promises implementation, as well as support for async blocks (also a libraray feature) in the upcoming version. - On top of that, you can use java.util.concurrent or any other Java-based concurrency package without any impedance mismatch, like Netty. - If necessary, you can also drop down to things like Threads, Locks, Queues, synchronization, @volatile variables or sun.mis.Unsafe. - Actors offer solutions for higher-level concerns of concurrency, like distributed computation, failure tolerance and communication over unreliable networks. (I think the best question whether you need Actors is: “Is there a chance that message X never reaches the receiver?” If the answer is no, there is pretty much no point in using actors.) (There are currently some improvements under-way to make sure that no state can be accidentally captured in Actors, Futures, etc.) - In addition to that you also have things like the Akka Dataflow libraries, Rx-style approaches or functional reactive programming. - You can also use the STM library (or agents, ...) if it is the best tool for the job (most concurrency people in Scala say that STM is conceptually a dead-end though). I hope the explanation helps a bit!

Skinney 13y ago
> It's not like in Go where people claim that channels and “goroutines” are the solution to every problem or how the Clojure community treats STM/Agents. Well... Go offers mutexes (and other synchronizing constructs) becouse Go admits that goroutines and channels, while great for alot of problems, doesn't solve everything. Rich Hickey also just announced a new library bringing "goroutines" and channels to Clojure. Both Go and Clojure communities know that there are certain problems not suitable for their prefered concurrency tools, but that doesn't mean that new functionality can't be added as libraries, as in Scala. > Scala has a full range of immutable & persistent as well as mutable & concurrent data structures available. In general, they are faster and more efficient than the ones in Clojure, due to the heavy tuning they received and the fact that you can pick the implementation which has the best performance characteristics for your use-case You can still pick other datastructures specialized for your usecase in Clojure, or create your own persistant or mutable datastructures. All collections from Java, including arrays, are also available, and if these fits better than Clojure's default collections then you are free to use them. The default and easiest option is still to use Clojure's persistant collections as well as atoms, refs and agents for changing state. Since using mutable collections and datastructures requires a little more syntax, most developers will use the persistant collections and the concurrency primitives provided by Clojure. This in turn makes it easier to refactor concurreny into your code, as you normally don't have to change mutable collections to their persistant alternative, and you don't have to check if the procedural code you may have written is thread-safe. On the flip side, Scala makes it easier to write performant code in a single-threaded setting, mostly becouse working with mutable datastructures and/or procedural code in Clojure isn't really natural, or shall we say "The Clojure Way". > - The collection library supports data-parallel operations since 2.9, but I think it's great that Clojure tries to catch up! Well, Clojure has had data-parallel operations bultin long before the new reducers library was available (pmap amongst others). > - Additionally, Scala offers a standardized Future&Promises implementation, as well as support for async blocks (also a libraray feature) in the upcoming version. Clojure has had Futures&Promises since the beginning, and asynchrounous code (go-blocks and channels) is available in the upcomming clojure.async library. > - On top of that, you can use java.util.concurrent or any other Java-based concurrency package without any impedance mismatch, like Netty. True, using java libraries causes a little impedance mismatch, but is still easy to do. Using stuff from java.util.concurrent is even encouraged when the builtin primitives just won't do. > - If necessary, you can also drop down to things like Threads, Locks, Queues, synchronization, @volatile variables or sun.mis.Unsafe. Same in Clojure > - Actors offer solutions for higher-level concerns of concurrency, like distributed computation, failure tolerance and communication over unreliable networks. (I think the best question whether you need Actors is: “Is there a chance that message X never reaches the receiver?” If the answer is no, there is pretty much no point in using actors.) (There are currently some improvements under-way to make sure that no state can be accidentally captured in Actors, Futures, etc.) "Pretty much no point in using actors" is IMHO an overstatement, but to each his own. What you say regarding improvements underway to prevent capturing external state is very interesting, and should be a great improvement for safe concurrent operations.

Skinney 13y ago

> It's not like in Go where people claim that channels and “goroutines” are the solution to every problem or how the Clojure community treats STM/Agents. Well... Go offers mutexes (and other synchronizing constructs) becouse Go admits that goroutines and channels, while great for alot of problems, doesn't solve everything. Rich Hickey also just announced a new library bringing "goroutines" and channels to Clojure. Both Go and Clojure communities know that there are certain problems not suitable for their prefered concurrency tools, but that doesn't mean that new functionality can't be added as libraries, as in Scala. > Scala has a full range of immutable & persistent as well as mutable & concurrent data structures available. In general, they are faster and more efficient than the ones in Clojure, due to the heavy tuning they received and the fact that you can pick the implementation which has the best performance characteristics for your use-case You can still pick other datastructures specialized for your usecase in Clojure, or create your own persistant or mutable datastructures. All collections from Java, including arrays, are also available, and if these fits better than Clojure's default collections then you are free to use them. The default and easiest option is still to use Clojure's persistant collections as well as atoms, refs and agents for changing state. Since using mutable collections and datastructures requires a little more syntax, most developers will use the persistant collections and the concurrency primitives provided by Clojure. This in turn makes it easier to refactor concurreny into your code, as you normally don't have to change mutable collections to their persistant alternative, and you don't have to check if the procedural code you may have written is thread-safe. On the flip side, Scala makes it easier to write performant code in a single-threaded setting, mostly becouse working with mutable datastructures and/or procedural code in Clojure isn't really natural, or shall we say "The Clojure Way". > - The collection library supports data-parallel operations since 2.9, but I think it's great that Clojure tries to catch up! Well, Clojure has had data-parallel operations bultin long before the new reducers library was available (pmap amongst others). > - Additionally, Scala offers a standardized Future&Promises implementation, as well as support for async blocks (also a libraray feature) in the upcoming version. Clojure has had Futures&Promises since the beginning, and asynchrounous code (go-blocks and channels) is available in the upcomming clojure.async library. > - On top of that, you can use java.util.concurrent or any other Java-based concurrency package without any impedance mismatch, like Netty. True, using java libraries causes a little impedance mismatch, but is still easy to do. Using stuff from java.util.concurrent is even encouraged when the builtin primitives just won't do. > - If necessary, you can also drop down to things like Threads, Locks, Queues, synchronization, @volatile variables or sun.mis.Unsafe. Same in Clojure > - Actors offer solutions for higher-level concerns of concurrency, like distributed computation, failure tolerance and communication over unreliable networks. (I think the best question whether you need Actors is: “Is there a chance that message X never reaches the receiver?” If the answer is no, there is pretty much no point in using actors.) (There are currently some improvements under-way to make sure that no state can be accidentally captured in Actors, Futures, etc.) "Pretty much no point in using actors" is IMHO an overstatement, but to each his own. What you say regarding improvements underway to prevent capturing external state is very interesting, and should be a great improvement for safe concurrent operations.