[erlang-questions] Erlang and the learning curve

[Henning Diedrich]

On 1/4/11 12:31 PM, Morten Krogh wrote:
> As soon as you want to control memory and performance,
> functional languages can actually be much much harder. And I mean much 
> harder. 

Yes but it may matter way fewer times than you seem to imply. As has 
been pointed out that
holds only in cases where you plan to do the optimization yourself down 
to a deep level.

But inbetween, e.g. for the right list representation, you have four 
flavors in Erlang to optimze
for performance. That's more than in, say, JS or Lua where you have 
basically one. Erlang is not
religious Haskell in that regard and there are many more cases where 
Erlang opted for the practical
solution.

Also, there's at least one imperative language, Python*, where the 
mantra is that your time
is expensive, not the hardware that will provide for faster execution. 
In other words, development
time should be optimized, not execution time. So yours seems not to be 
an argument for imperative
  languages per se. Some reject that view voluntarily.

It simply depends on what you want to do. Finally, you get stuff for 
free in Erlang that you have
to code or use libraries in other languages, as results from 
share-nothing memory and micro-
processes. Think scaling on multi-core. That is really not trivial for 
other languages and where
performance-gains are coming from today. I am not sure if you are aware 
to what degree e.g.
Python, even Stackless Python simply forfeit that whole playing field 
wholesale, last time I checked.

Of course you can mimic functional or share-nothing in, e.g. C. But have 
one programmer mess
up and he can ruin everybody elses discipline with horrendous errors. In 
Erlang you simply can't.
(Or, let's say, it's way harder).

Best,
Henning