"Am I the only one who see's this as blatant link bait?"
Lau Jensen is a known pro Clojure troll with a history of dissing other languages with not much knowledge about those languages. See the discussion at http://news.ycombinator.com/item?id=1771595 for links to where he attempts to discredit Scala, C# and Python (the last of which, in retrospect, is mildly funny, since a Clojure port of Norvig's Sudoku solver ended up slower than Python).
fwiw he's even made dumb comments on the Clojure dev process and got told off by Rich Hickey.(who said about one of his blog posts "tl;dr: This blog post is the idle chatter of people who are not involved in the Clojure development process in any significant way. Lau has never submitted a single patch. Apparently his free lunch isn't arriving fast enough." http://news.ycombinator.com/item?id=2055543)
I wouldn't pay him much attention (I am surprised this article got so many upvotes). He writes inflammatory stuff all the time. Think Jon Harrop minus the competence.
He does come across as smug, but as far as I can see, the clojure version is indeed both smaller and correct compared to the longer and buggy scala version.
This is true, but to be fair, rightly or wrongly those are the technologies that are put forward by the designers as the primary solution for concurrency problems in the respective languages.
ScalaSTM looks good though and the comparison would be interesting.
What's wrong with this place that that gets downvoted to 0?
Have people actually looked at books on scala or clojure, or the respective websites?
Odersky's "Programming Scala" a whole chapter on actors entitled "Actors and Concurrency", which leads with an introduction about the problems with threads and how Actors provide a solution. There's no mention of STM. STM is not in the scala standard library and is an experimental feature right now. It would be unreasonable for someone evaluating the language today to regard STM as an available solution for concurrency, and if you follow Martin Odersky's advice, you'd use Actors.
All of the major clojure books, on the other hand, devote their concurrency chapters to STM and Clojures's concurrency primitives that are designed to work with it, and Rich Hickey is pretty clear that this is the way to go.
I think it's reasonable to compare the two approaches since they are the native idiomatic way in each language. The very fact that STM is coming soon to Scala suggests that Actors may not be enough. Don't people want to see the two compared?
It is notable that both languages are flexible enough that STM or Actors can be implemented as libraries.
The philosophy behind Clojure is that there is a right way of doing things and a wrong way of doing things, and Clojure won't let you do things the way it considers to be wrong.
The philosophy behind Scala is that you can do whatever you want. It might nudge you in certain directions, but it won't force you. The language is designed to be flexible enough to support several paradigms. Actors was a demonstration of this: you can build some of the syntax and semantics of Erlang actors into Scala as a library, rather than a core feature of the language. Likewise with ScalaSTM: it's purely a library, rather than a core feature of the language.
If you pick a problem that's well suited to STM, you can use STM in Scala. If you pick a problem that's well suited to Actors, you can use Actors in Scala. If you pick the wrong tool for the problem, well, then yes, you'll find yourself in a lot of pain.
The Scala philosophy of actors just being a demonstration has been somewhat lost when you look at the literature, where Actors are presented as a solid solution.
STM doesn't really exist in Scala except as an experiment, so you cannot use it in Scala unless you're prepared to seek out the experimental library.
Yes, yes, I know it's planned for inclusion and code is being tested, but that's not the same as shipping today in the base library. I agree that Scala is all about flexibility "a scalable language" etc, but in practice we're talking about comparing a future Scala feature with today's Clojure.
I don't see how you can say that Clojure 'won't let you' use actors. It would seem to me just as easy to implement an actors library in Clojure as to implement STM in Scala. Rich Hickey has even suggested himself that Actors may show up for use in distributed systems in a future Clojure.
My point is that this is a reasonable comparison between the current versions of the languages that most people are likely to encounter. If a journeyman programmer has a concurrency problem to solve in each of the languages today, they'll be guided towards the STM system in Clojure, and the Actors library in Scala.
The original article which compares the two is actually quite insightful in exposing difficulties with using Actors. Given that the solution was taken from a prominent book on Scala and not contrived by the author, it's hardly a strawman. Why did the authors of the O'Reilly book pick actors if they're a bad choice?
If they're doing it wrong, it would be useful to explain why, than to just shoot the comparison down by saying Scala can do anything once the appropriate library has been written.
ScalaSTM is hardly experimental. Its reference implementation is based on CCSTM, which has been around for a while now. CCSTM was built by Nathan Bronson, who spent a good chunk of his working life building several transactional memory systems for use in the financial industry. Now he's at Stanford Pervasive Parallelism Lab, where he's built CCSTM and is part of the ScalaSTM expert group. I would have no qualms using ScalaSTM in production today.
Whether it is or isn't shipped with the "base library" seems like a red herring. Scala, today, supports the language features necessary to support ScalaSTM. Whether that's packaged and distributed with the language seems superfluous.
I never said Clojure won't let you use Actors. I said Clojure won't let you do things it considers to be wrong (e.g., mutable state shared between threads).
Like I said, this blog post was a comparison between Actors and STM, and I would have been more interested in seeing a comparison between Clojure's STM and ScalaSTM.
I only read part 2 but he's either not doing this seriously or he's overconfident in his thinking abilities.