Erlang Programming/Design Principles

Design Principles

Send Messages, do not share memory

Messages are sent between processes. The compiler is very picky about what operations are "parallel-safe" and is not shy about letting you know. The compiler is particularly picky (parallel-safe) about sending and receiving messages. If you recurse after each message is processed then your code is more parallel-safe. Messages are delivered in order and are selected for removal from the queue by pattern matching (as in Prolog). Because of the extensive built-in pattern matching, Erlang operates in a declarative way. Because of the parallel-picky compiler, it is often as easy to write a parallel program in Erlang as it is to write a serial program in other languages, once you get the hang of the language.

Fail Early and Often

Erlang designers often use an unusual but effective design technique called "fail early and often", FEO. Let processes fail. If unexpected inputs arrive, then let the process crash, and restart it. This allows for terse code that is robust. We do not waste time coding for bad inputs. We code to expected inputs(the specification only). Theoretically, this technique should make for improved security because unexpected inputs cause processes to self destruct and errors and bad behaviour do not propagate.

Debugging

Once a process has crashed we can gather crash information and let the programmer fix problems early. If a process is written to specification, and it crashes then the only possible problem is that it received bad input.