Erlang OTP Glossary of Terms

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).