Hi everyone,

Can any one give a comparison between Clojure and Erlang on concurrent
programming?

Both of them are kinda pure functional programming language, which
avoiding the state changes in general. Erlang provides message passing
mechanism to handle the inter-thread communication, while Clojure uses
the transactional memory. The difference probably would lie in that
Erlang provides a light-weight process module to support great amount
user-land process, making the scheduling cost much less, but as for
Clojure, since the codes will eventually executed in JVM anyway, I
guess it would still use the java implementation of thread.

I'm very curious about the difference between these two in the aspect
of concurrent programming. Which one would be more efficient? So, I
would be appreciated if any of you guys can give more information on
this.

Thank you!

http://www.pragprog.com/magazines/download/1.pdf
Page 16
RH talks about Erlang and Scala vs Clojure in an interview
I found it to be a very useful comparison.

On Sep 18, 8:54 am, dongbo <dongb.w...@gmail.com> wrote:

On Sep 17, 6:54 pm, dongbo <dongb.w...@gmail.com> wrote:

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.

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.

-SS

On Fri, Sep 18, 2009 at 17:41, Stuart Sierra

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.

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:

{set,3,16,16,8,80,48,
     {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
     {{[[{foo,3},4,5]],
       [],[],[],[],[],
       [2],
       [],[],[],[],
       [1],
       [],[],[],[]}}}
with Closure's:
#{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.

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

A million thanks to you guys!

To ss: concise and clear. very helpful!
To Wojtek: very detailed, I'll bear your suggestion in my mind! Thanks
a lot
To Timothy: thanks for sharing!

-dongbo

I think there are 2 kinds of concurrency: local concurrency (one
machine) and distributed concurrency (parallel).

Is there a comparison about the speed of local concurrency of Clojure
and Erlang?

I would like to create an online multiplayer game server which serves
thousands of persistent flash connections. On a single machine
(something like Intel i7 with 6GB RAM), can JBoss Netty + Clojure beat
gen_tcp + Erlang?

Thanks.

I'd recommend an architecture where you utilize ejabberd and create
bots/components that read XML stanzas and react. That way you can just
scale your application servers separately and use any language you
choose. You also get chat for free.

With respect to Stuart's comment above - "Erlang is designed for
distributed operation across many machines; Clojure is designed for a
single machine with many cores.", how are Clojure and Haskell
different? I am just curious to know how do Haskell, Clojure and
Erlang compare.

On Sep 24, 4:36 am, Lance Carlson <lancecarl...@gmail.com> wrote:

Clojure and Haskell both include STM systems for controlled access to
shared resources. There's a Haskell distribution known as Glasgow
Distributed Haskell (GdH), which provides facilities for small-scale
distributed programming. Clojure can achieve the same effect through
the use of third-party libraries (JMS, JGroups, Terracotta, etc...).

I started learning Haskell before coming to Clojure, and from my
experience, Clojure has a much lower barrier to entry. Haskell is an
extremely dense language with a good number of syntax rules and
rigorous type system. Clojure, being a lisp, is very easy to grok
syntactically and easier to learn IMO. Haskell has been around for
almost 20 years. The compiler is extremely advanced, and programs have
a reputation for blinding speed. Clojure runs on the JVM, so you get
the benefit of your programs running almost everywhere without any
fancy deployments and get all the standard libraries that Java
includes.

I spent a few months learning Erlang last year, and I have to say that
it's almost like it's own operating system. It's extremely good at
what it does, but it's use cases are targeted towards the development
of distributed network applications with a high level of fault
tolerance. If you're writing a server using a custom protocol and need
to spread it across multiple nodes and use supervisor trees to
guarantee availability, Erlang is for you. In order to quickly
schedule thousands of micro-threads, it makes some sacrifices at the
scheduler level. This means that things like I/O are going to be less
performant than with other languages.

Comparing the three languages, I'd look at them as follows.

1) Haskell - mathematics oriented, high performance, high learning
curve
2) Clojure - general purpose lisp, JVM, concurrency oriented
3) Erlang - network oriented, high availability, distributed

They're all worth learning. Which is best suited really depends on
what you're trying to do. I'd suggest the following resources.

Haskell - "Real World Haskell" (available for free online)
Clojure - "Programming Clojure" (available through the pragmatic
programmers)
Erlang - "Programming Erlang" (also available through the pragmatic
programmers)

-Travis

On Sep 24, 10:24 am, mmwaikar <mmwai...@gmail.com> wrote:

Excellent summary of each language's sweet spot. I'd like to suggest a
different book for Erlang though.

For learning Erlang, I'd suggest Erlang Programming by Francesco
Cesarini & Simon Thompson, published by O'Reilly

...

--
Omnem crede diem tibi diluxisse supremum.

2009/9/24 wmacgyver <wmacgy...@gmail.com>:

Yes, this is definitely the best book currently available on Erlang.
It's amazing how well it seems to hit both the introductory and more
advanced ends of Erlang and its environment.  Joe's book was good (but
a little shallow), this is indepth yet accessible.

Having had the pleasure of spending a good couple of hours with both
the authors I can say that not only do they really know their stuff,
but that they're both excellent at explaining things...  With
Francesco being CTO of Erlang Training & Consultants (one of the
oldest (and probably the oldest) Erlang consultancy companies -
outside of Erricson) and Simon being a long established academic &
authority on functional programming as well as author of what is
regarded by many as the best text on Haskell, they have a talent for
explaining things simply.

The other thing I find striking about this book, is that it's very
much a practical book geared at people using Erlang to solve real
world problems.  There is little talk from ivory towers here, just the
nitty gritty details of Erlang, concurrency and high-availability
engineering.

Anyway, I'm just glad that we now have two practical (real-world)
functional languages available to us, Erlang and Clojure.  As others
have said,  Erlang is a more specialist language than Clojure and in
its niche it is undisputed king...  However Clojure, being built on
the JVM is more suited to a wider variety of problems (think
everything that Java was used for + everything lisp or scheme is great
at with some bonus points for combining these worlds so well).

R.

Thanks everyone for your enlightening responses.

On Sep 25, 3:35 am, Rick Moynihan <rick.moyni...@gmail.com> wrote: