
Sleeping Barber: Clojure x Scala - DanielRibeiro
http://www.bestinclass.dk/index.clj/2009/09/scala-vs-clojure-round-2-concurrency.html
======
freshhawk
Am I the only one who see's this as blatant link bait?

I only read part 2 but he's either not doing this seriously or he's
overconfident in his thinking abilities.

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

What do you think he's missing?

~~~
jorgeortiz85
He's comparing Actors to STM, not Scala to Clojure.

I'd be more interested in a comparison of Clojure's STM to ScalaSTM
(<http://nbronson.github.com/scala-stm/index.html>).

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

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

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

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

------
grimlck

        for (i <_- style="color: #afeeee; font-weight: bold;" span="span" _="_" _20="_20" to="to" _1="_1">val customer = new Customer(i)

??

It took me a minuet to figure out that was a bug in the HTML page, and not
some obscure scala syntax i haven't seen yet ;)

------
rbanffy
For whoever misses part 1:

[http://www.bestinclass.dk/index.clj/2009/09/scala-vs-
clojure...](http://www.bestinclass.dk/index.clj/2009/09/scala-vs-clojure-lets-
get-down-to-business.html)

