Table of contents

DONE

The Erlang Rationale

paper

%3 cluster_7dde41a5_a406_41ef_93a5_ca5b5e563ab3 The Erlang Rationale cluster_26a33412_fe9d_4a4d_9a3f_94cd3e451eee Especially interesting (for me) _fda0a366_d8bb_41a6_8c11_ae04097feef4 Distribution _54ef38c9_e523_4388_a5ef_80cf077a89b8 Jobs _1a8a5dd6_0d64_4d57_93ca_e95a3e2fb73c Records _f0dec2bf_20ec_4970_9f30_45f85d18ab6a Erlang __0:cluster_7dde41a5_a406_41ef_93a5_ca5b5e563ab3->_f0dec2bf_20ec_4970_9f30_45f85d18ab6a 
This is a description of some of the basic properties and features of Erlang and
an attempt to describe the rationale behind them. Erlang grew as we better
understood the original problem we were trying to solve, telephony, and as we
evolved the basic concepts for solving the problem.

Especially interesting (for me)

  • It's difficult to pick some specific parts, and it goes into more detail than shown here. Keep in mind that this are little snippets to show the type of elements discussed, not the depth of the discussion.

Distribution

 

Distribution was always meant to be transparent, if so desired. This meant process
communication and error handling must work the same for distributed processes as
for local processes.

Jobs

 

Using process groups it is very easy for different applications to have
different default i/o channels. For example some could be communicating through
separate windows, some directly to a file and some over TCP to another system (a
browser interface to Erlang).

One problem with running multiple applications concurrently is that if more than
one is communicating with the user through the same channel then the i/o will
become very jumbled.

The solution to this was to introduce the concept of a ‘job’ and a user driver
which controls which job is currently connected to, and hence communicating
with, the user. _A job is a process group together with its group leader._

Records

 

Records were added to solve a problem for our first customer. They were good users
and we really wanted to help them. What they wanted was:

- Named fields in tuples, preferably with default values.
- Not slower than doing it explicitly with element/setelement, if it was slower
they would not use it.

These requirements basically meant that everything had to be done at compile time,
finding fields at runtime would just not cut it. This forced records into being a
compile-time construction which went against the grain of rest of Erlang. Together
with macros they are still the only compile-time constructions in the language.

For simplicity it was decided not to create a new data type but to use tuples.

  • Goes on to describe the design choices and trade-offs involved on the implementation of records.