Actually behaviours predate Elixir by about 15 years. Elixir has inherited them from Erlang/OTP and uses some the standard OTP behaviours, like gen_servers, supervisors and applications, and extended them by adding some new behaviours, agent and task. Doing this is nothing strange as the behaviour concept is easily extensible both by design and implementation.

While this is an initially useful comparison it ultimately is a grossly oversimplified view.

OTP Design Principles: 1.2 Behaviours

From the OO perspective behaviours need to be understood in terms of the intent of the Template Method pattern:

• Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure. (GoF)

i.e.

• Define the skeleton of a process, deferring some functionality to the callback module.

In Template Method the AbstractClass does expose an interface (implying a contract) that will be common to the ConcreteClasses but AbstractClass also contributes the common behaviour (which an interface cannot). In some ways the Template Method pattern is a compile time version of the Strategy pattern:

• Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. (GoF)

i.e.

• Define a family of processes (workers) which can be uniformly supervised and managed. Callback modules lets the process computation vary independently from how it is supervised and managed.

Similarly a behaviour module is in charge of most of the standardized (common) aspects of the process lifecycle while the callback module primarily deals with the specific computation (work) that the process is responsible for.

Behaviours are module based and are sometimes used at compile time to vary production and testing module implementations but that is a degenerate use case.

During runtime (process instantiation) a process composes the behaviour and callback module - i.e. it’s only through processes that a behaviour module can spawn “multiple instances” of the behaviour, each process manifesting a specific binding between a behaviour and a callback module with its own state.

Designing for Scalability with Erlang/OTP p.10:

OTP generic behaviors can be seen as formalizations of concurrent design patterns.

So from the OTP perspective behaviours are about processes, not FP.

See also:
Erlang Behaviors - …and how to behave around them (1/2)
Erlang Behaviors - …and how to behave around them (2/2)

Here’s Joe’s take

https://twitter.com/joeerl/status/1087697399034929152