On Fri, Sep 18, 2009 at 17:41, Stuart Sierra
<the.stuart.sie...@gmail.com> wrote:
>
> On Sep 17, 6:54 pm, dongbo <dongb.w...@gmail.com> wrote:
>> Can any one give a comparison between Clojure and Erlang on concurrent
>> programming?
Hi! I'd add 2cents here as I did some hacking in Erlang and now i'm
transforming lots of habits to try coding in Clojure efficiently.
> Erlang supports one concurrency model, Actors. Clojure supports
> several -- Agents, which are similar to Actors; Refs, which have ACI
> (not D) transactional semantics; and Atoms, which have atomic updates.
>
> Erlang is designed for distributed operation across many machines;
> Clojure is designed for a single machine with many cores.
Yeah, Erlang makes distribution easy and gives you a nice way to send
any term (a nested data structure, including closures inside) across
the network and read it on the other node, even if the nodes have
different OS architecture underneath. It also means such data is
serializable for free - you can write it to a file or just keep it as
a binary blob for a while in your program - and you don't have to
write any serializing implementation for your specific data
structures, it just works by calling term_to_binary and
binary_to_term. I found it a killer feature for some code I wrote.
OTOH Erlang's data structures are not unified as in Closure in that
they all are immutable. Most of the OTP modules you'd use for your
data - sets, trees, dicts - operate on purely functional data. But
then some other (say, digraphs) are implemented over ETS, which is
really a server encapsulating some state. So you can't serialize such
stuff as I described above, you have to export it first to some 'pure'
structure and import on the other side. So, you should carefully read
the docs to see what are you dealing with. As you work with such
different stuff, it becomes obvious these implementations were added
as language evolved to cover the needs of various users, incl.
commercial ones. I mean, the high-level data structures weren't
designed from the ground up as in Clojure, rather they were
implemented in different ways using low-level structures: atoms, lists
and tuples, and made their way to Erlang's standard lib.
So, if you are into FP and like the idea of all the data being
immutable, Closuje is a breeze - data structures behave predictably
and they pretty-print nice, which is important if you live in a REPL.
Compare a standard way of creating and printing some nested data, Erlangs:
> sets:from_list([1,2,[{foo,3},4,5]]).
{set,3,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
{{[[{foo,3},4,5]],
[],[],[],[],[],
[2],
[],[],[],[],
[1],
[],[],[],[]}}}
with Closure's:
> #{1 2 '([foo 3] 4 5)}
#{1 2 ([foo 3] 4 5)}
Sucintness is power, isn't it?
In Erlang you probably would want to roll your own pretty-printer for
such simple thing as a set, or just run sets:to_list() every time you
print it human-readably, but still there's no easy way to convince the
REPL to do it for you.
> Erlang is designed to hot-swap entire modules in a running production
> system; Clojure is not.
>
> Erlang has its own light-weight thread model; Clojure threads are JVM
> threads, which are usually operating system threads.
>
> You can't really say that one approach is more efficient than another
> without reference to a specific problem.
Very well put.
I'd say: if your system must be concurrent *and* distributed, go for
Erlang and you will get used to it. Even if Erlang has only an Actor
model, it's a very powerful model and they did it right. If you only
need concurrency on one node, it's worth to try both Erlang and
Clojure and make a decision based on early symptoms ;]
If you like Lisp you can also try LFE which is a Lisp over Erlang, but
that's another story.
cheers,
Wojtek
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
