erlang real system sizing and metrics.

Joe Armstrong joe@REDACTED
Wed Dec 16 08:44:39 CET 1998

> In a recent post to the mailing list it was mentioned that erlang has 
> been used in large systems within Ericsson. Without gettin into the 
> proprietary details of these projects would it be possible to get 
> some detail that addresses: 
>        1. The General Applications (or Systems) that were built or are    
>          being built. 
	For obvious reasons we can only point you at the open literature.
	A good source of information is

	In particular browse the stuff in the archive and 
in "CeBit'98 Special" - this is a special issue of Erlang news describing
products built in Erlang and presented at CeBit.

	Another good jumping off place is 

>          4. Complexity of developed systems i.e. use of supervisors,      
>              event handing, fault tolerance & load sharing behaviors,          
>              number of nodes involved in distributed system.

    This is difficult  to answer. One of the  the design goals  of the
supervisors,  client-server behaviours etc.   was to "abstract out the
details  of the concurrency"     - It's *much*  easier  to  understand
sequential code than concurrent code. Our goal was that 95% of all the
application  programmers would     never  "see" a    process  (or  the
concurrency structures used).   

    This has turned out  rather well - It  appears that a small number
of design patterns  (supervision  trees, client-server, event-handler,
etc.) suffice  for   a high  percentage  of all  the application  code
(whether it's  95%  or not  I don't know  -  but it is   large) - the
exceptions are sufficiently small that they can easily be handled by a
small team.

    System  design then becomes "choosing from a number of 
pre-defined design patterns" rather than a totally unconstrained process.

    The design patterns that have evolved (and  which are included in
the  distribution)  are those   we have  found   useful in build large

    The  Complexity of these systems is  "manageable" is the sense that
to  understand  the  design you  first  have  to understand the design
patterns  and what they  are good for and then  you have to understand
how the problem maps onto the design.

    As for the number of nodes in an application this ranges from 1 to
a max of round about 40 (from memory the 40  were two clusters one of 5
nodes the other of 35 - the clusters where in two different towns),


More information about the erlang-questions mailing list