Erlang (was: Re: Generics)

Richard A. O'Keefe ok at cs.otago.ac.nz
Tue Sep 30 02:54:09 UTC 2003


Daniel Vainsencher <danielv at netvision.net.il> asked:
	Sorry about the off topic interjection, but can you write a
	paragraph or two about Erlang?  I've tried to get the flavor of
	it from site/documentation, but haven't quite made it yet.

These days, Joe Armstrong (who is quite taken with Squeak graphics, btw)
talks about "Concurrency Oriented Programming".  He says
[Concurrency Oriented Programming Languages] are characterised by
the following six properties:

1. COPLs must support processes.
   A process can be thought of as a self-contained virtual machine.

2. Several processes operating on the same machine must be strongly
   isolated.  A fault in one process should not adversely affect
   another process, unless such interaction is explicitly programmed.
   ... Two processes operating on the same machine must be as
   independent as if they ran on physically separated machines.

3. Each process must be identified by a unique unforgeable identifier.
   We will call this the Pid of the process.

4. There should be no shared state between processes.  Processes
   interact by sending messages.  If you know the Pid of a process
   then you can send a message to the process.
   ... Location transparency: you send a message to a process the same
   way no matter what machine it's on, you don't _have_ to care about
   locations.

5. Message passing is assumed to be unreliable with no guarantee of
   delivery.
   a. Message passing is atomic: a message is either delivered in
      its entirety or not at all.
   b. Message passing between a pair of processes is ordered
      [If P1 sends X then Y to P2, P2 will receive X before Y].
   c. Messages should not contain pointers to data structures contained
      within processes--they should only contain constants and/or Pids.
      [Reason: if sender crashes or laters data, what happens to message?
      "Constants" includes lists and tuples.]

6. It should be possible for one process to detect failure in another
   process.  We should also know the reason for faiure.
	
He also wrotes that
There are six essential requirements on the underlying operating system
and programming languages:

R1. Concurrency - Our system must support concurrency.  The computational
    effort needed to create or destroy a concurrent process should be
    very small, and there should be no penalty for creating large numbers
    [explained elsewhere as hundreds of thousands]
    of concurrent processes.

R2. Error encapsulation - Errors occurring in one process must not be
    able to damage other processes in the system.

R3. Fault detection -- It must be possible to detect exceptions both
    locally (in the process where the exception occurred) and remotely
    (we should be able to detect that an exception has occurred in a
    non-local process).

R4. Fault identification - We should be able to identify why an
    exception occurred.

R5. Code upgrade - there should exist mechanisms to change code as it is
    executing and without stopping the system.

R6. Stable storage - we need to store data in a manner which survives
    a system crash.  [More precisely, we need to store *selected* data
    in a manner which survives a system crash].

----------------------------------------------------------------

Those really are the essential ideas, everything else is just one
particular realisation of them.

The main thing where Squeak falls down is "isolation".  Just as Erlang
gets "stable storage" via a library (Mnesia), so Squeak gets it through
Magma &c.  Just as Erlang can replace modules, so Squeak can replace
classes.  Just as Erlang has exception handling, so Squeak has exception
handling.  Erlang has very cheap concurrency; I don't think Squeak's is
quite as cheap, but it's not as heavyweight as some languages.

Erlang is a mostly-functional language; Erlang data structures are immutable.
Squeak is an object-oriented language; Squeak data structures are most of
them shared mutable objects.  For the ways Squeak is normally used, Squeak
data structures are a Good Thing.  But for the kinds of process and fault
isolation that Erlang wants, immutable data structures are better:  another
process can't change your data structures because _nobody_ can.

Pretty much everything else follows from that, plus the historical accident
that Erlang was first implemented as an interpreter written in Prolog.

Squeak and Erlang are so far from being rivals in my view that I've written
UBF reading and writing code for Squeak.  (UBF is a compact "wire" protocol
that has recently been developed for Erlang.  You can think of it as not
entirely unlike a very stripped down YAML with built-in compression of a
sort.)



More information about the Squeak-dev mailing list