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