[erlang-questions] Erlang and the learning curve

[Morten Krogh]

On 1/4/11 5:33 PM, Henning Diedrich wrote:
> 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.
>
What are those four flavors?


> 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.
>
Of course, you can always build a slow language, both functionally and 
imperatively.
The question is if it is possible to build a fast functional language, 
especially without making BIFs and NIFS for everything.
And then the functional language is just a glorified C library.

> 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.
This multicore stuff is somewhat off topic.
Multicore scaling is pure performance oriented, which you and many 
others claim is not so important.
Why bother about multicore when single core performance is considered 
premature optimization?

But I am curious about what you mean.
You think Erlang will scale better than the fast imperative languages 
like C? What makes you say that?

Is the claim that the otp team will write a better user space threading 
(process) library than anyone else?
Even in that case other people could copy their code. I assume the 
scheduling and migration code is in C not Erlang or what?

The kernel people, working at a lower level and in C, has an advantage. 
They can integrate user threads with kernel threads.
For instance, how will Erlang solve the problem that the Erlang thread 
on a given core could be preempted by the kernel right after an Erlang 
process has been migrated to that core?

I think it is fair to say that the jury is still out here.

I think Erlang will do very fine. It is just that I am not as 
pessimistic about the other languages. Especially not C.
Maybe Java's garbage collector will get stuck when we get to thousands 
of cores. Possibly.
But not imperative languages in general.


Morten.


> 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
>