4 ms·

Clojure uses STM and has persistant datastructures by default. This makes it pretty safe when it comes to concurrency. Clojure also has good support for paralel

by Skinney 13y ago

Clojure uses STM and has persistant datastructures by default. This makes it pretty safe when it comes to concurrency. Clojure also has good support for paralellism through pmap and reducers. Making something run in paralell is often just changing the name of a function or importing a diffrent namespace. I don't know Scala that well, but actors in scala still shares state, and doesn't give the same level of protection when it comes to changing state. Actors also introduce some overhead in case you just want to read a single variable from a datastructure safely. You have to send a command and receive a message, wheras in clojure you just retrieve the value you want. Actors however are, to my knowledge, easier to scale across machines as actors doesn't necessarily have to be in the same process, or even on the same machine.

dkhenry 13y ago
Over the years Scala has adopted some of the concurrency primitives from clojure, now I think if you compare the two there isn't much of a difference between them, however when you start to add in third party libraries I think Scala is actually pulling ahead of clojure. With Akka not only does it do single node concurrency well it also does multinode concurrency with two or three extra lines of code.
- Skinney 13y ago
  Well, when you add in third-party libraries, Clojure can use these too. I wasn't aware Scala had incorporated Clojuires STM, I thought Scala was married to Actors/Akka?
  - dkhenry 13y ago
    Akka has implementations of STM, and a few other niceties from Clojure land. Also your right Clojure can use Akka just like scala so neither is any better for it, but scala can call native clojure code too. What I have found Awesome is that I can work on a scala project or library and hand it off to my co worker who is a clojure guy and he can incorporate it.
happy_dino 13y ago
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.
yummyfajitas 13y ago
Scala uses STM and has persistent datastructures by default. http://doc.akka.io/docs/akka/2.1.4/scala/stm.html http://doc.akka.io/docs/akka/2.1.4/scala/stm.html

by Skinney 13y ago

dkhenry 13y ago

Over the years Scala has adopted some of the concurrency primitives from clojure, now I think if you compare the two there isn't much of a difference between them, however when you start to add in third party libraries I think Scala is actually pulling ahead of clojure. With Akka not only does it do single node concurrency well it also does multinode concurrency with two or three extra lines of code.

Skinney 13y ago
Well, when you add in third-party libraries, Clojure can use these too. I wasn't aware Scala had incorporated Clojuires STM, I thought Scala was married to Actors/Akka?
- dkhenry 13y ago
  Akka has implementations of STM, and a few other niceties from Clojure land. Also your right Clojure can use Akka just like scala so neither is any better for it, but scala can call native clojure code too. What I have found Awesome is that I can work on a scala project or library and hand it off to my co worker who is a clojure guy and he can incorporate it.

happy_dino 13y ago

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.

yummyfajitas 13y ago

Scala uses STM and has persistent datastructures by default. http://doc.akka.io/docs/akka/2.1.4/scala/stm.html http://doc.akka.io/docs/akka/2.1.4/scala/stm.html