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 `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.
If you enjoyed this content, please consider sharing this link with a friend, following my GitHub, Twitter/X or LinkedIn accounts, or subscribing to my RSS feed.