how to design large erlang systems

[Ulf Wiger]

Den 2005-04-19 18:46:35 skrev Martin Ankerl <martin.ankerl@REDACTED>:

> Hi! A few days ago I have started to look at Erlang, and so far I
> really like it. Having mostly OOP background, I am very curious how
> large software systems are designed in Erlang. I mean, I can design
> large object oriented systems with class hierarchies, namespaces,
> packages etc; while in erlang each file is one module (in case I did
> not miss something).
> Are there any documents for design patterns or best-practices for how
> to write large Erlang applications?
> I would also be very interested in some kind of "Erlang for Java
> /C#/Ruby/Python developers" document :-)

Some papers from the AXD 301 experience can be of some use:

"Four-fold Increase in Productivity and Quality"
Ulf Wiger, FemSYS 2001, Munich
http://www.erlang.se/publications/Ulf_Wiger.pdf

"World Class Product Certification Using Erlang"
U. Wiger, G. Ask, K. Boortz, SIGPLAN Erlang Workshop,
Pittsburgh, 2002
http://www.erlang.se/workshop/2002/Wiger.pdf

"Trouble Shooting a Large Erlang System"
Mats Cronqvist, SIGPLAN Erlang Workshop, Snowbird 2004
http://www.erlang.se/workshop/2004/cronqvist.pdf


Here and there in the above documents, suggestions are
offered as to why Erlang works well for large system
design:

- The language is easy to learn
- Very expressive syntax gives short readable programs
- Very powerful debugging support

I think one of the most important factors is that
Erlang helps in building systems of loosely coupled
components, where the number of unwanted dependencies
is kept to a minimum. Several aspects contribute to
this, but perhaps the CSP-style concurrency support
is the most important contributor.

Hoare's book on Communicating Sequential Processes
can be downloaded for free here:
http://www.usingcsp.com/cspbook.pdf

Of great interest is for example his discussion on
concurrency on page 209:

"In its full generality, multithreading is an incredibly
complex and errorprone technique, not to be recommended
in any but the smallest programs. In excuse, we may plead
that it was invented before the days of structured programming,
when even FORTRAN was still considered to be a high-level
programming language!
A variation of the fork command is still used in the UNIX(tm)
operating system. The fork does not mention a label. Its effect
is to take a completely fresh copy of the whole of storage
allocated to the program, and to allocate the copy to a new
process. Both the original and the new process resume execution
at the command following the fork. A facility is provided for
each process to discover whether it is the parent or the
offspring. The allocation of disjoint storage areas to the
processes removes the main difficulties and dangers of
multithreading, but it can be inefficient both in time and
in space. This means that concurrency can be afforded only
at the outermost (most global) level of a job, and its use
on a small scale is discouraged."

One may object that with Erlang, concurrency of the sort
Hoare describes is no longer so inefficient that its use
on a small scale must be discouraged.

/Uffe