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.
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.