[erlang-questions] Erlang and the learning curve

[Henning Diedrich]

Hi Morten,

to get that straight up front: I am not arguing against imperative 
languages or against the virtues of C.

This thread is about approaching an FP language, Erlang and I am 
addressing your argument that
performance is an argument against any FP language. Or /can/ be as you 
correctly put it.
And the keyword in all this was 'ease'.

That 'can' seems to introduce a troubled logic and to induce some 
talking past each other.
With 'can' you qualified correctly that it is /not/ always the case that 
FP /cannot/ be
optimized, or by extension, could even come optimal right out of the box.

So I am arguing two things: performance optimization is not always 
important, it is sometimes not
even limited in FP. At the least. I would even say it is rarely 
important, and it is mostly not limited.
We need not not agree on that, it will be hard to measure. Finally, it's 
no argument against the
ease of FP languages, specifically Erlang, but to the contrary, it 
performance can in the future
more and more be on the side of FP, in a perfectly batteries included 
way: you don't have to
bother at all, which is the ultimate ease obviously.

Also note, I absolutely love C and speed. And I do know the limitations 
of Erlang where raw calculation
power is concerned. And I would still not use FORTRAN. Which is a good 
parallel, by the way, because
you could do anything you do in FORTRAN in C, right, and probably 
optimize it further. Then why would
FORTRAN /still/ exist? For the ease of the speed. Because it gives a 
better ratio of ease to speed.

On 1/4/11 8:25 PM, Morten Krogh wrote:
>  On 1/4/11 5:33 PM, Henning Diedrich wrote:
> > On 1/4/11 12:31 PM, Morten Krogh wrote:
> >
> > 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?

The ets: set, ordered_set, bag and duplicate_bag. They are integral to 
Erlang and yes, that's not so FP,
it's pure side effects. Erlang can be very practical where it has to. A 
good thing.


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

But it does illustrate how explicitly unimportant performance can be, no 
matter if FP
or imperative. And that imperative does not mean fast, or even optimisable.

>  The question is if it is possible to build a fast functional
>  language, especially without making BIFs and NIFS for everything.

Yes that is possible and Erlang is. But that was not /actually/ the 
question, that
was 'ease', and there Erlang mostly beats C by a long margin, C + MPI 
even longer. This is not
just touchy feely estimation, it's a result of the implications of 
share-nothing processes.

And that is no co-incidence, that distinction comes from Erlang's 
origins. It was made to be
fool proof to a much higher degree than C. It has defense 'built in' as 
opposed to C, and
way more sensibly than most other languages. It was made for parallel 
environments, as
opposed to C. That was not as important a while back as it has become 
now with the
advent of multi-core CPUs [7] AND of clusters as the new normal. That's 
why CouchDB [4]
or Scalaris/x [5] exist and are written in Erlang.

But the OP's question was on learning the language, getting the picture 
and you weighed in that
FP /can/ be hard to optimize for speed, which I said is true but neither 
always important nor true
without the qualifying 'can'. And if we need to wind to there, that was 
your qualified answer to the
issue of 'ease of learning'.

>  > On 1/4/11 10:17 AM, Joe Armstrong wrote: Functional programming is
>  > *much* easier to understand than imperative programming.
>  >
 > Definitely not much easier. It depends on the problem, and whether 
you include
 > performance requirements. As soon as you want to control memory and 
performance,
 > functional languages can actually be much much harder. And I mean 
much harder.

As illustrated by imperative languages that reject performance to be 
their purpose out of hand,
your point won't count as a general point against an FP language that 
matters in all cases.
I think we agree there. Yes, there are things for C as BIFS and NIFS 
illustrate and that's just fine.
You can always go there. It's not the only spot where Erlang likes to be 
sequentiality.

>  And then the functional language is just a glorified C library.

No, where do you take that from? Do you know what happens if you try to 
program continuation-
passing style in an imperative language? You can do that but it has 
nothing whatsoever to do with
ease any more. And single value variable binding becomes the natural 
thing to do on the way [8].

Yes they're all Turing complete and you can use MPI, and you might in 
the end use libevent to get
the most out of a certain task. But again that doesn't take the "can" 
qualifier out of the argument,
it can be true, but often it doesn't matter and for many cases it is not 
even true in the first place.

> > 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. It
> > simply depends on what you want to do. Finally, you get stuff for
> > free in Erlang that you have
>
>  This multicore stuff is somewhat off topic.

it is hardly off topic if you talk about performance?

Python can't really use it so well, C needs quite a bit overhead and 
offers a plethora of ways
to kill yourself, Java looses it's niceness and presents programmers 
with dead lock opportunities
who were quite glad to leave 0 pointer induced core dumps behind.

>  Multicore scaling is pure performance oriented, which you and many
>  others claim is not so important.

Then what are we talking about? We are talking about how and why it may 
not be important
in all cases, and even for the cases that it is, the qualifying "can" 
applies as to optimization limits.

>  Why bother about multicore when single core performance is considered
>  premature optimization?

Something is missing in that sentence I guess. But again, for one it is 
not a killer argument
against FP, and above that Erlang gives you stuff free that can cost you 
tripping up your
favored C parallel library.

Sure with endless time you can do everything in assembler and be faster 
then anything else,
including C. Coming back to 'ease' ...

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

Because what is good scaling for your? A thousand node MySQL cluster? It 
is being done and billions are
earned from it. But not because it actually works that well. More likely 
because it was to late to change
at some point.

Good scaling in the sense of less painful, with Erlang you don't even 
having to think about a parallelization
step (well, almost not) that's a lightyear from bringing MPI in to C 
once the logic works. And that is
because Erlang was made for this and does prevent certain things that 
become painful when you try
to distribute stuff and there, Erlang processes, in their 
share-nothingness, are in fact an advantage.

>
>  Is the claim that the otp team will write a better user space 
threading (process) library than anyone else?

No, it's that the Erlang makers did it for you already in a way 
intimately woven into the fabric of the language
so it's 'transparent' compared to the pains of getting familiar with, 
say C and on top of it, MPI.

>  Even in that case other people could copy their code. I assume the
>  scheduling and migration code is in C not Erlang or what?

You mean it's all really C, and there is no end to optimizing?

C might be about the only language you could use to emulate Erlang stuff 
and be faster, at the usual price.
But unless you use Erlang as a library, maybe to write a domain language 
that might look like Erlang proper
and then tweak a bit, maybe using an interface like NIFs ... it won't be 
anything but easy or at a good
ease to speed ration.

The gains from FP /are/ intrinsic in the language features. You don't 
have them when using straight
imperative style.

But sure Erlang "is" C underneath. So are most other languages, which 
cannot really be a point
when discussing languages, or no other languages should exist in the 
first place, see FORTRAN.

>
>  The kernel people, working at a lower level and in C, has an
>  advantage. They can integrate user threads with kernel threads.

Where are you going here? That you *can* be faster than an Erlang 
program? That was my very first
word: yes. And it's not the point.

That there are ways to be faster than ANY Erlang program? 
Scientifically, 100% yes. But hardly the
point either, as it applies to all languages, including C, if you dig 
deep enough.

>  [snip of convenience]
 >
 > Maybe Java's
>  garbage collector will get stuck when we get to thousands of cores.
>  Possibly.

It gets stuck as soon as you go beyond 2GB. I mean, not officcialy, but 
in reality. And that is about global memory. [3]

Best,
Henning

[1] http://www.erlang.org/doc/man/ets.html
[2] https://computing.llnl.gov/tutorials/mpi/
[3] 
http://blogs.forrester.com/john_r_rymer/10-06-21-why_im_worried_about_javas_future
[4] http://couchdb.apache.org/
[5] http://www.onscale.de/scalarix.html
[6] 
http://stackoverflow.com/questions/641326/what-is-the-difference-between-multicore-programming-in-erlang-and-other-language
[7] http://www.gotw.ca/publications/concurrency-ddj.htm
[8] http://en.wikipedia.org/wiki/Static_single_assignment_form