On Nov 22, 4:57 pm, Robin <robi...@gmail.com> wrote:

It's a fun comparison, but one I'd like to be careful about. Clojure
has a different philosophy about concurrency than does Erlang, neither
being right or wrong, but yielding somewhat different results as you
encounter each decision point in the design. The difference is, I
think, (and I'm hesitant to speak for Erlang, which I quite respect
and am no expert on):

In Erlang the concurrency model is (always) a distributed one and in
Clojure it is not.

I have some reservations about unifying the distributed and non-
distributed models (see e.g. http://research.sun.com/techrep/1994/smli_tr-94-29.pdf),
and have decided not to do so in Clojure, but I think Erlang, in doing
so, does the right thing in forcing programmers to work as if the
processes are distributed even when they are not, in order to allow
the possibility of transparent distribution later, e.g. in the failure
modes, the messaging system etc. However, issues related to latency,
bandwidth, timeouts, chattiness, and costs of certain data structures
etc remain. My experiences with transparent distribution were with COM
and DCOM, and, quite frankly, not happy ones. I think Erlang has a
much better story there, but the fact is that distributed programming
is more complex, and I personally wouldn't want to incur that
complexity all the time. I think it is ok for a system designer to
decide one part of a system will be distributed and another not, and
incur some rewrite if they are wrong. If I wrote phone switches I
might think otherwise :)

Clojure has a synchronous reference mutation model in its STM and I am
wrapping up an asynchronous reference (actor) model for Clojure. The
basic idea is that actors are mutable references to immutable values.
An actor reference can be made to refer to a new immutable value
(only) by sending it a message. Messages are functions (and,
optionally, additional arguments) that are applied to an actor's value
and whose return value becomes the actor's new value. Message sends
return immediately and the actual work happens asynchronously in a
thread pool. Because messages are functions they can also be
multimethods and therefore messages are potentially polymorphic. Also,
because the set of functions is open, the set of messages supported by
an actor is also open, a sharp contrast to pattern matching message
handling loops. Another significant feature of Clojure's actors is
that the value of an actor is always immediately available for reading
without any messages, i.e. observation does not require cooperation/
coordination. This represents, IMO, a substantial reduction in
complexity versus other models, but is incompatible with distribution.
Clojure actors are integrated with its STM - any messages sent in a
transaction are held until it commits, and are discarded if it is
retried or aborted. Clojure's actors are reactive - there is no
imperative message loop and no blocking receive.

Even with actors, Clojure will not yet have a distributed concurrency
story, but I am considering just adopting Erlang's wholesale, using
Jinterface for Clojure<->Clojure or even Clojure<->Erlang distributed
processes. Maybe that will look like Termite when it is done. Stay
tuned.

Rich