Erlang/OTP Glossary

OTP.md

Erlang/OTP Glossary

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).
• 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 called (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.

SICK! Using Riak in production now. Have been prolonging "looking under the hood". Thanks for the round up!