Erlang hints from an CO junkie

[Joe Armstrong]

On Wed, 11 Aug 2004, Vlad Balin wrote:

>> The important bit is that  the user only sees the protocol (ie
>> the messages) between the application and the town process and not any
>> internal details of *how* the town process is implemented.
>
>>   Note we are not doing OO programming here we are doing CO programming.

> Well, from the design point of view, you're describing OO approach in terms
> of Alan Key.
> "Objects are the base building blocks, objects has the state, objects
> communicate
> with each other using messages." See citate below.

I don't really understand this kind of statement.

1) In OO design you must identify the different objects involved
2) In CO design you must identify the different concurrency patterns involved

1) in not the same as 2)

  I also dislike this "everything is an object" way of thinking.

   Saying "Objects are the  base building blocks,  objects have
state, objects communicate with each other using messages." is weird to me.

   How can a string have state? How can you send a message to a string?
The string  "joe" is just a  constant data structure. It  has no state
and you can't send it a message.

   Take integers, for example, how can the integer 42 have state? How can
you send it a message?

   Some OO text say that 42 + 10 should be interpreted as meaning

   "send a + message, with argument 10 to the 42 object"

   I have always thought that this was the height of daftness.

   As for the idea of bundling together data structures and methods into
the same unit of abstract and calling this an object is even sillier.

   In my way of thinking we can model things using the following
things.

    a) Pure data structures (described by types)
    b) Pure functions which transform data structures into different
       data structures
    c) Processes. Processes are little virtual machines. They have state
       (state is just some class (a) data). You can send them messages (messages
       are class (a) data structures). They might respond with messages.
       They are independent - if they crash no other processes should be
       affected.

    Data structures (a's), functions (b's) and processes (c's) are all
fundamentally different types of things - they should not be mangled
together and called objects.

   Design is "making you mind up" - how do I model my problem into
a's, b's and c's?.

   ...


>
>>   In  Concurrency Oriented  (CO)  programming you  concentrate on  the
>> concurrency  and  the messages  between  the  processes.  There is  no
>> sharing of data.
>
>>   An Erlang should  be thought of thousands of  little black boxes all
>> doing things  in parallel  - these black  boxes can send  and receive
>> messages.  Black boxes can detect errors in other black boxes - that's
>> all.
>
>>   At  the  design level  of  abstraction  how  things work  internally
>> *inside* a  black box  is irrelevant -  the programming  language used
>> inside  a BB  be it  a functional  or imperative  or OO  or relational
>> language is irrelevant.
> _____________________________________________________________
> The first Smalltalks were in the middle of the progression of
> designs. The objects in Smalltalk-72, for example, implemented a kind
> of top down recognizer that parsed the messages and responded. There
> were no separate methods, and each object was essentially a looping
> process (like a machine on the internet) waiting for a message to
> parse.
>
> This is very similar to where several Prolog derivatives got to later
> on (including Erlang). Hewitt's Actors used this idea in many
> interesting and important ways.
> 						- Alan Key
> _____________________________________________________________
>
>>    Erlang uses  a simple functional language  inside the BBs  - this is
>> not particularly interesting - *any*  language that does the job would
>> do - the important bit is the concurrency.
>
> Not only the functional language, but very _slow_ functional language,
> with boxed computations and dynamic typing. Also, it should be unsafe
> since it's not easy to check types at compile stage.
>


   But it is not slow - where did you get this strange idea from?

   This entirely depends upon the benchmark you choose.

   Here are a few benchmarks where I guess Erlang would win

     1) - Create 100,000 processes. Make them into a ring.
          send a message round the ring 120 times. Kill all the
          processes
     2) - Do 1) on a cluster of 100 machines putting 1000 processes
          on each machine
          Let 10% of the machines crash at random.
 	 Make the other machine recognise the crashes and reconstruct the
          ring
     3) - Take two machines. One machine one perform a computation.
          Let a client accesses machine one. If machine one crashes
          then the client should failover to machine two and not notice
          that machine one has crashed

   << My guess is that not only would Erlang win, but also things like
1) would be *impossibly* to write in many other languages >>

   Take a look at http://www.sics.se/~joe/apachevsyaws.html to see how
Erlang shapes up against C (This is Apache vs. yaws <yet another web server> -
yaws is written in Erlang - yaws totally outperform apache in the non-trivial
problem domain (ie when the machines are heavily overloaded) - in the
trivial domain (lightly loaded machines) the performance is identical.

> If language is _really_ irrelevant, why should you recommend anyone to use
> slow and unsafe Erlang? This simple functional language has a number
> of obvious disadvantages. Why not Smalltalk, for example? :))
>

   You have misunderstood - the  important thing about Erlang is how it
handles  concurrency and  errors.   The language  in which  sequential
computations are  performed is less important  (perhaps irrelevant was
overstating this) - the idea I want to get over is that Erlang is good
because of  the way  it handles concurrency  and errors -  NOT because
it's a good functional language.

   Erlang is not unsafe - where did you get this idea from?

   It's impossible to corrupt memory. If processes do something silly
(like dividing by zero) there are two orthogonal methods to trap the
error and deal with it (catch .. throw) and process links.

   If the two inbuilt mechanism fail - the OTP supervision trees will take over.

   And if the *entire* computer crashes neighbouring nodes (if you're
running distributed Erlang can detect and correct the errors)

   Erlang was designed for building fault-tolerant systems.

   The  Ericsson   AXD301  has  >2  Millions  lines   of  Erlang  code,
and 99.9999999% reliability. This might be the most reliable product ever
built by Ericsson.

   What are the "obvious disadvantages" ????

   Why  not  Smalltalk? -  what  happens if  the  computer  on which  a
smalltalk  system is running  crashes? -  can other  smalltalk systems
running on other  nodes detect this and handle the  error? Can this be
done in the language itself?

   << aside

 	in districted Erlang

 	Pid = spawn_link(Node, Fun) (or whatever)

         Creates a remote process on Node. If the entire machine crashes
you get a exit signal from Pid. This is defined in the language and
is not dependent upon the underlying OS>>


   Why would I recommend Erlang?

   Firstly, I  might not recommend  Erlang, this would depend  upon the
problem. But if the problem were appropriate then I'd say:

   Because it  works. Because  it's easy to  learn, because there  is a
rock solid implementation....

   Because you can make big industrial scale products using the technology.

   Cheers

/Joe