Language Bindings for Erlang Again (Opinion)

[Joe Armstrong (AL/EAB)]

> -----Original Message-----
> From: owner-erlang-questions@REDACTED 
> [mailto:owner-erlang-questions@REDACTED] On Behalf Of Jeff Crane
> Sent: den 6 juni 2006 02:40
> To: erlang-questions@REDACTED
> Subject: Re: Language Bindings for Erlang Again (Opinion)
> 
> > > > Basically, it sounds like you are inventing problems 
> where there 
> > > > aren't any. Why?
> 
> Erlang is not some utopian language. There must be large or 
> multiple problems to prevent adoption when implementing the 
> most trivial of tasks. First, Erlang is not adopted because 
> it is not exceptionally good at satisfying basic project 
> goals like speed, maintainability, and efficiency. 

This last sentence is crazy - "speed" depends upon the combination
of problem and language NOT on language alone.

Erlang *is* a lot slower than (say) C - for (say) compressing a file,
but
a lot faster for (say) creating large sets of parallel processes.

So where is Erlang great? - for things like web servers, where you
want to protect each of the users from each other. In a convential
server like Apache you have to spawn one OS process/connection
in order to protect the sessions from each other. This is very slow.

In Erlang you spawn one Erlang process/connection which is a very
lightweight
operation - so FOR WEB SERVERS Erlang is *much* faster than C or php or
whatever.

This is why Erlang is being used at for, example, jabber.org, just
because Erlang
can handle vast numbers of parallel sessions.

Erlang also maps nicely onto multi-core CPUs - why is this? - precisely
because
we use a non-shared lots of parallel processes model of computation. No
shared
memory, no threads, no locks = ease of running on a parallel CPU.

Believe me, making your favourite C++ application run really fast on a
multi-core CPU
is no easy job. By the time the Java/C++ gang have figured out how to
throw away 
threads and use processes and how to structure their application into
small lightweight
processes they will be where we were 20 years ago.

Does this work? - yes - we are experimenting with Erlang programs on the
sun Niagara
- the results are disappointing our message passing benchmark only goes
18 times faster
on 32 CPU's - but 18 is not too bad - if any C++ fans want to try the
naigara all they
have to do is make sure they have a multi-threaded version of their
application, debug
it -'cos it probably won't work and they can compare their results with
us (and I'm not
holding my breath)

Turning a sequential program in a parallel program for the niagara is
really easy.

Just change map/2 to pmap/2 in a few well chosen places in your program
and sit
back and enjoy.

Efficency comes from a correct underlying architecture, ie in this case
being able
to acuatlly use all the CPUs on a multi-core CPU.

The ability to scale and application, to make it very efficient, to
distribute it
depends upon how well we can slit the application up into chuncks that
can be evaluated in
parallel. Erlang programmers have a head start here.

> In small 
> standalone programs, it's unlikely that anyone would consider 
> Erlang over a purely interpreted language. 

Not true - I can find one counter example to "anyone" - that's me!

 


> As an employer, 
> it's near-impossible to find a person to maintain or support 
> my new Erlang project in any State, much less my County.

Have you advertised a job *in this group* - this mailing list is the
prime
place to advertise.

If it should happen that you cannot recruit an Erlang/Haskell/O'caml
programmer
in your State/county then I would be seriously worried - you are going
to be seriously
threatened by companies in other countries that DO use these
technologies and will
threaten your existence.

Suggestion - keep away from on-line banking and credit assesments -
Erlang is
expanding rapidly in this niche.

Guess what - I work for Ericsson - we use Erlang - it gives us a market
advantage
over companies that do not use Erlang. We are market leaders in
telephony over ATM
etc.

If *other companies* (TM) do not use Erlang that's fine by me - we can
then outcompete them.
This is NOT a level playing field - If N companies all use the *same*
technology
then *nobody* has any advantage - you can't win by doing the same thing
as
everybody else - you might be a wee bit better but you can't win.

> The 
> amount of Erlang the average programmer (me) needs to write 
> to perform the same work as 12 lines of ASP, is beyond reasonable.
> 

Example, please - can you show us the 12 line ASP program, so we can
show you how this would be done in yaws.

> The difficulty in bridging to other languages is what stifles 
> adoption within my peer group. I have no examples of Erlang 
> binding nicely to anything but C++.
> A month of digging and posting in my free time (that 99% of 
> Erlang dabblers will not bother with regardless), I still 
> dont have Erlang talking to Python (which I'm also learning).

Binding Erlang to other languages is really easy AND
safe. Why? because we only really allow bindings through a socket.

In the "good old Unix" days nobody ever talked about "language bindings"
We talked about pipes and sockets.

In a UNIX shell we would write

	> foo <in | bar | baz | bingo | bla | whoops > out

We pipe the output of foo into bar then baz then bingo etc.

bar, baz,bingo etc. could be written in ANY programming language.

What people do today is to create "language bindings" this usually means
"linking different programming language code into the *same* memory
space"

This particular act of lunacy guarantees that faults that crash my
program will
also crash your program - 

As I have often pointed out - then most important problem to solve in
making
any system is to stop errors propagating. If my program is super fast,
wonderful
great, tested, etc. it makes no difference if your program can crash my
program.

So how can we isolate programs.

Easy - I run my program on a machine in Australia, you run yours on a
machine in
Ulambatar - and make sure there is no network connection between them.

But can we do better than this? - can we run them on the *same* machine
- yes
if we isolate them using processes. This is what the process is for, it
is a
unit of isolation.

Unfortunately, most programming language designers *forgot* to put
processes in their
languages - so you have to use OS processes to protect you applications.

Do people do this? - no - why not? because OS processes are expensive
*very* expensive.

So what do they do instead? - LINK THEIR APPLICATIONS INTO THE SAME
MEMORY SPACE and
USE THREADS. - both a receipt for disaster - why? Because we have
violated our most
important principle - STOP ERRORS FOR PROPAGATING.

(Sorry for shouting) 

Back to the subject - Erlang *is* easy to interface to any external
language
because the ONLY way this is possible is through a defined protocol on a
socket.
Now that other language are not good at this is hardly a problem for
Erlang.

This (separation through a socket) has many added benefits.

	- it enforces separation of components
	- it raises the abstraction level of an interface
	- when thing go wrong you know who is to blame
      - you can put a policeman on the interface and check that both
	  parties follow the protocol
	- distributing the application is easy
	- parallelising the application on a multi-core CPU is easy



> 
> Personally, I'm using Erlang for its strengths. Is it better 
> than RakNet? It's certainly easier to implement! and that's 
> worth something...but it's not exactly presented as a 
> prototyping language.

Erlang is a programming language *designed* for building highly scalable
fault-tolerant distributed soft real-time applications.

RakNet is "a C++ UDP based network library designed to allow programmers
to add response time-critical network capabilities to their
applications. It is mostly used for games, but is application
independent."

You can't compare a fully fledged programming language with a C++
library for message passing.

> 
> I first bought into the advantages of Joel Reymont when he 
> presented findings through the OpenPoker project. I also 
> examined the criticisms, which were never really addressed. 
> Anyone can whip up a large program that passes numbers around 
> registers and point out "see how fast it is". How scaleable, 
> realtime, is a large Erlang program? Where are the 
> performance tests over 100m of cat5? I'll test it myself and 
> then I'll know.

Most of my programs don't "pass numbers around registers".

And you don't just "whip up a large program" - large to me
means > 1 mega line of code - these take years to write.

We could, I guess, make a small well-defined benchmark and
talk about this, but it would be more sensible to contribute to the
great language shootout.

Cheers

/Joe

> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
>