"Erlang is a programming language originally developed at the Ericsson Computer Science Laboratory. OTP (Open Telecom Platform) is a collection of middleware and libraries in Erlang. Erlang/OTP has been battle tested in a number of Ericsson products for building robust fault-tolerant distributed applications, for example AXD301 (ATM switch). Erlang/OTP is currently maintained by the Erlang/OTP unit at Ericsson" (erlang.org)

Start here

For installation instructions see Installation topic.

Links

1. Official Erlang site: https://www.erlang.org
2. Popular package manager for both Erlang and Elixir: http://hex.pm
3. Erlang Patterns: http://www.erlangpatterns.org/

What is an iolist?

It's any binary. Or any list containing integers between 0 and 255. Or any arbitrarily nested list containing either of those two things.

Original article

Use deeply nested lists of integers and binaries to represent IO data to avoid copying when concatenating strings or binaries.

They are efficient even when combining large amounts of data. For example combining two fifty kilobyte binaries using binary syntax <<B1/binary, B2/binary>> would typically require reallocating both into a new 100kb binary. Using IO lists [B1, B2] only allocates the list, in this case three words. A list uses one word and another word per element, see here for more information.

Using the ++ operator would have created a whole new list, instead of just a new two element list. Recreating lists to add elements to the end can become expensive when the list is long.

In cases where the binary data is small, allocating IO lists can be greater than appending the binaries. If the binary data can either be small or large it is often better to accept the consistent cost of IO lists.

Note that appending binaries is optimised as described here. In short, a binary can have extra, hidden space allocated. This will be filled if another binary is appended to it that fits in the free space. This means that not every binary append will cause a full copy of both binaries.

gen_server is an important feature of Erlang, and require some prerequisite to understand every aspect of this functionality:

• Loop, recursion and state
• Spawning processes
• Message passing
• OTP principles

A good way to learn more about a feature in Erlang is to directly read the source code from official github repository. gen_server behavior embed lot of useful information and interesting structure in its core.

gen_server is defined in gen_server.erl and its associated documentation can be find in stdlib Erlang documentation. gen_server is an OTP feature and more information can be also found in OTP Design Principles and User's Guide.

Frank Hebert give you also another good introduction to gen_server from its free online book Learn You Some Erlang for great good!

Official documentation for gen_server callback:

• code_change/3
• handle_call/3
• handle_cast/2
• handle_info/2
• init/1
• terminate/2

Warnings

• Do not use 'count'=>infinity and element restart in your plan.
  like:

Childspec = #{id => foo
             ,start => {bar, baz, [arg1, arg2]}
             ,plan => [restart]
             ,count => infinity}.

If your process did not start after crash, director will lock and retries to restart your process infinity times ! If you are using infinity for 'count', always use {restart, MiliSeconds} in 'plan' instead of restart.

• If you have plans like:

Childspec1 = #{id => foo
              ,start => {bar, baz}
              ,plan => [restart,restart,delete,wait,wait, {restart, 4000}]
              ,count => infinity}.

Childspec2 = #{id => foo
              ,start => {bar, baz}
              ,plan => [restart,restart,stop,wait, {restart, 20000}, restart]
              ,count => infinity}.

Childspec3 = #{id => foo
              ,start => {bar, baz}
              ,plan => [restart,restart,stop,wait, {restart, 20000}, restart]
              ,count => 0}.

Childspec4 = #{id => foo
              ,start => {bar, baz}
              ,plan => []
              ,count => infinity}.

The rest of delete element in Childspec1 and the rest of stop element in Childspec2 will never evaluate!
In Childspec3 you want to run your plan 0 times!
In ChildSpec4 you have not any plan to run infinity times!

• When you upgrade a release using release_handler, release_handler calls supervisor:get_callback_module/1 for fetching its callback module.
  In OTP<19 get_callback_module/1 uses supervisor internal state record for giving its callback module. Our director does not know about supervisor internal state record, then supervisor:get_callback_module/1 does not work with directors.
  Good news is that in OTP>=19 supervisor:get_callback_module/1 works perfectly with directors :).

1> foo:start_link().
{ok,<0.105.0>}

2> supervisor:get_callback_module(foo_sup).
foo

3>

Why recursive functions?

Erlang is a functional programming language and don't any kind of loop structure. Everything in functional programming is based on data, type and functions. If you want a loop, you need to create a function who call itself.

Traditional while or for loop in imperative and object oriented language can be represented like that in Erlang:

loop() ->
  % do something here
  loop().

Good method to understand this concept is to expand all function calls. We'll see that on other examples.