Haskell vs. Lisp vs Erlang for Concurrency Oriented Programming? - BitGeek
======
BitGeek
History- Learned Lisp in High School in the 1980s. Since then, procedural
(Pascal & C) and then about 17 years of object oriented development.. C++,
Java, Ruby, Objective-C.

I am interested in concurrency oriented programming now... and have been
directed to Erlang. Others seem to talk about Lisp alot. (I remember enjoying
it, but feeling that it wasn't too practical.. but it was only the 3rd or 4th
language I learned and I was 17 at the time.)

What seems to be the natural parallelism in Erlang really appeals to me. The
1960s era syntax does not. (I still think in objects.) I haven't investigated
Haskell much, or Lisp recently.

If one wants to solve a problem that is naturally highly parallel (like
raytracing) what language would you recommend?

I'm open to hearing about other languages than the ones I mentioned.

I'm not interested in careful programming to be thread safe, or mutexes, etc.

Also, I don't really want to start a flame war... but haven't seen many
opinions, or specifically an argument for Lisp from a concurrency viewpoint.
And if there's a much better language than Erlang out there, I'd love to find
out about it now.

And of course, meta arguments by posting links to others advocacy of
particular language also appreciated.

~~~
vikram
Scheme is cleaner than common lisp. I think Gambit-C has an implementation of
Erlang's message passing and mailbox idea for each process and in addition to
that it doesn't use OS threads for individual processes it uses first class
continuations. In one test it performed similar to Erlang running as many as
900K processes on a 1GB ram P4.

<http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03309.html>

Having said this. I'm really interested in Erlang because of mnesia. I'm not
sure if I want to spend a bit of my life writing a database in Gambit.

Here are thoughts from someone who choose Erlang over Scheme.
<http://theschemeway.blogspot.com/>

I don't really agree with his point of view. I think if your problem doesn't
really have a strong concurrency element in it which you would solve by using
shared data then it probably doesn't make sense to use the message passing
model. Having said that if you are writing for the web one day it definitely
will have a strong need for concurrency.

~~~
BitGeek
Thanks very much for the pointers! I followed up on them and they led to some
interesting reading... still leaning toward erlang.

------
boris
I'm not interested in careful programming to be thread safe, or mutexes, etc.

This is like saying I am not interested in solving any real problem, just in
concurrency for the sake of it.

~~~
BitGeek
On the contrary, it is simply saying I've already rejected that strategy since
it doesn't actually solve the problem. You cannot grow a shared memory system
efficiently.

Since someone has actually solved the problem, I'm going with that solution...
but was asking if there was an even better solution.

