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
For learning Erlang, I'd suggest Erlang Programming by Francesco
Cesarini & Simon Thompson, published by O'Reilly
On Thu, Sep 24, 2009 at 11:16 AM, tmountain <tinymo...@gmail.com> wrote:
...
> 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
>
--
Omnem crede diem tibi diluxisse supremum.
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.