Christopher Smith wrote:
Frankly, by treating mutation as a special case, it puts the focus in
the right place, where most of the bugs come from, simplifies
concurrency, transactions, etc. It also allows you to do the kind of
transformations of functions that really end up being helpful.
It does still have some rough edges, as the language still needs some
maturing, but there is nothing about it that makes it inherently bad
beyond programmers having difficulty with functional languages in general.
I'm not convinced yet. I keep watching Haskell, but it seems that quite
a few people launch into a project using Haskell and then shift to
something else after a bit because it winds up having a touch too much
friction. A good example is:
http://wagerlabs.com/2006/01/01/haskell-vs-erlang-reloaded
Followed by Erlang.
I just wish it had a JVM-based version. It would give me a lot more
confidence in its long term prospects.
JVM's have their own issues with concurrency. ;-) I'll go with Erlang's
runtime.
I'd rather have *both*. The Erlang runtime is tuned toward remote node
messaging. Something like Termite does better when the messages stay on
a local node because of the shared heap. Given that much concurrency is
going to be local, it's not clear that the Erlang runtime is tuned
correctly for that.
Having a separate implementation allows you the choice of the most
applicable tuning rather than one which might not fit.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
