Erlang hints from an CO junkie
Thu Aug 12 10:33:11 CEST 2004
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
> 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
a) Pure data structures (described by types)
b) Pure functions which transform data structures into different
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
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
>> 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
> 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
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
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?
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.
More information about the erlang-questions