Erlang OTP in a Nutshell
Erlang is a functional programming particularly suited for building distributed systems. It's main characteristics are:
- Lightweight processes: Normally, one or multiple processes are created and live only long enough to handle a single request. Thousands of processes may be running at any given time.
- Immutability: Variables are assigned only once and their values can not be changed. You can not issue any of destructive update on a data structure after creation. So brush up on functional data structures! There are, however, built-in hashtable structure called ETS tables that do allow updates, even concurrently.
- Message passing: It has a built-in mechanism for communicating between processes, even when they are running in different nodes. Data structure serialization is well defined by the language, and you can even pass functions around in some cases.
- Dynamic language: It runs on a virtual machine designed for, among other things, hot code swapping. Entire applications can be upgraded without stopping them. It is also extremely easy to interact and debug a production system.
- Inter-process links: Processes can establish links between them and be notified when other process exit (or exit themselves).
The OTP framework provides an abstraction layer on top of erlang. It defines applications, which have well defined initialization and stop points, that can depend on other applications. It also has abstractions for a number of special type of processes, among them:
- Supervisors: Processes that watch over other processes and handle their failures. Child processes may in turn be supervisors themselves, forming a process hierarchy.
- Generic servers: Processes that handle requests, which can be synchronous or asynchronous.
- State machines: Processes that live in one of a finite number of states and respond to events in possibly different ways depending on the current state.
The above are called OTP behaviors. Normally you would create a module and mark it as an implementation of one of these behaviors, then implement the callbacks required by that behavior. This saves you from reinventing the wheel, but you need to familiarize yourself with what is required to implement each behavior and when to expect the OTP framework to call your callback functions.
To learn more about Erlang and OTP, I recommend this amazing free guide: