Erlang OTP Glossary

Date: January 10, 2012 Last modified: January 10, 2012

I am hoping this will serve as a reference for coworkers and others new to Erlang and OTP to be able to figure out the terminology easier than I had to. I learned the hard way, so you don't have to!:)

  • Erlang/OTP - The set of libraries and conventions that are used as part of the core Erlang distribution by Ericsson to build fault-tolerant, distributed systems more effectively.

  • OTP Release - A fully deployable distribution to run on an "Erlang node" (see below). An OTP Release may have one or more OTP Applications running inside of it at any time.

  • OTP Application - Usually a stateful long-running and active set of Erlang processes that collaborate together to achieve a well-defined set of responsibilities. It is a packaging of these collaborating modules and processes into a directory structure (see 'OTP Application Conventions' below) along with metadata about the OTP Application and default/fallback environment variable values (in case the OTP Release above doesn't provide any values for them).

  • OTP Application Resource File - Contains metadata and environment variable value defaults/fallbacks for the OTP Application.

  • OTP Application Callback Module - For all active OTP Applications a callback module providing the `application` Erlang behaviour must be defined and export `start/2` and `stop/0` as per the expected contract (see [OTP Application manual](http://www.erlang.org/doc/design_principles/applications.html)).

  • OTP Supervisor - Each active OTP Application Callback Module will start a root supervisor to run the different components of the application inside of a supervision tree.

  • OTP gen_server - A supervisor can launch one or more workers and/or one or more supervisors to create the supervision tree. One type of OTP defined behaviour is a `gen_server` that enables the very common client/server semantics. A `gen_server` callback/implementation module is launched as an Erlang process that can keep state running in a loop and receive messages sent from other Erlang processes. These messages may be `call`ed (i.e. the client blocks until the `gen_server` implementation replies) or can be `cast` (i.e. the client sends and forgets that it sent that message).

  • OTP gen_event - A lesser used OTP defined behaviour and broadcast module for event handling/broadcasting.

  • OTP gen_fsm - A lesser used OTP defined behaviour for FSMs.

  • Erlang behaviours - a defined/expected interface that a module is expected to export. Any deviation from the defined/expected interface for a module defined as providing this Erlang behaviour will show up as a compiler warning (not error).

  • Erlang node - one instance of a BEAM VM runtime, potentially having multiple OS processes in a process tree.

  • Erlang process - a very lightweight thread inside of the BEAM VM that only permits sharing global state via a process mailbox that can receive messages from other Erlang processes. The BEAM VM can create Erlang processes with very low resource consumption; with `+K true` passed in as a VM option upon startup, `epoll` (and other kernel polling mechanisms depending on the OS that Node.js/EventMachine utilizes) can be used to determine which Erlang processes are runnable at any moment, to minimize I/O blocking/wait times without impacting programming-style and impairing code readability/debuggability (which Node.js/EventMachine does drastically).

    Recommended Reading

Book:

  • OTP in Action - Manning Publishing: very useful for the budding Erlanger that wants to building production systems in OTP.

Online:

  • Learn You Some Erlang - Great online learning resource for Erlangers plus OTP beginner and intermediate developers.

Code:

  • Basho Erlang Projects - Often the best way to learn is by looking at a living breathing codebase that uses the language and/or libraries you are learning. A great source is Basho's Erlang projects. Check out rebar, lager, poolboy, riak_kv, riak_search and many more.