Cloud Parts

Elixir

A dynamic, functional language on the Erlang virtual machine, created by José Valim: Erlang’s processes, supervisors and hot code loading, with modern tooling, macros and gradual types being added to the compiler.

What it is
Programming languages (run on a virtual machine)
Type
Open source
Made by
The Elixir Team
License
Apache 2.0
Facts checked
8 October 2026

What it is

Elixir compiles each module to bytecode in a .beam file and runs on BEAM, the Erlang VM, so it inherits Erlang’s model whole: lightweight processes that share nothing and exchange messages, supervision trees, distribution across nodes, and per-process garbage collection. It calls Erlang code directly. Erlang modules are atoms such as :lists or :crypto, and Elixir discourages wrapping them in favour of calling them as they are, so every Erlang/OTP library is available from day one.

On top of that Elixir adds its own tooling and language features. Mix is the build tool that creates, compiles and tests projects and manages dependencies; IEx is an interactive shell and Livebook offers interactive notebooks. Macros, built with quote and unquote, transform code at compile time, although the guide recommends them only as a last resort. The ecosystem includes the Phoenix web framework with LiveView for real-time pages, Ecto for databases, Nerves for embedded firmware and Nx for numerical computing.

Elixir is dynamically typed, but since v1.17 (June 2024) the compiler has been gaining gradual set-theoretic types. It infers types from patterns and warns about common mistakes without requiring changes to existing code, and a dynamic() type covers values that are only checked at run time.

Why teams pick it

  • All of BEAM’s concurrency and fault tolerance, with direct access to every Erlang/OTP library and no wrappers
  • Productive tooling out of the box: Mix for builds, tests and dependencies, IEx for live debugging, Livebook for notebooks
  • A broad ecosystem around one runtime: Phoenix and LiveView for the web, Ecto for data, Nerves for devices, Nx for numerical work
  • Gradual set-theoretic types find bugs in existing code without asking for annotations

Watch out for

  • Still mostly dynamically typed: the type system covers a growing but incomplete set of constructs, so many errors still appear only at run time
  • Shares BEAM’s costs: messages are copied between processes, and the BeamAsm JIT does little optimisation across instructions, so tight CPU-bound loops gain less from it than from an optimising compiler
  • Macros make code generation easy and code reading harder; the official guide warns that explicit is better than implicit

Alternatives

What all run on a virtual machine have in common →

How it fits with other technologies

A process with its own state, and a direct call to an Erlang module · elixir

defmodule Counter do
  def start, do: spawn(fn -> loop(0) end)

  defp loop(n) do
    receive do
      {:incr, from} ->
        send(from, {:count, n + 1})
        loop(n + 1)
    end
  end
end

pid = Counter.start()
send(pid, {:incr, self()})

receive do
  {:count, c} -> IO.puts("count: #{c}")   # count: 1
end

IO.inspect(:lists.reverse([1, 2, 3]))      # [3, 2, 1]: Erlang’s lists module, no wrapper
IO.puts(:erlang.system_info(:schedulers))  # scheduler threads, one per logical CPU (e.g. 10)

See it in a real stack

No architecture uses Elixir yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2011–2024

José Valim started Elixir at the beginning of 2011 (the first commit is dated 9 January) and released v0.3.0 around April. Using it in real projects showed a bad early decision: Elixir tried to depart from Erlang, so every Erlang module needed an Elixir wrapper before it could be used, and Elixir would always be catching up. He paused, studied other languages, and set a new challenge: not to reinvent Erlang, but to offer more productivity and flexibility while staying 100% compatible with it.

The foundation of the current design came in October 2011, during a stay in San Francisco, with help from Yehuda Katz. The rewrite began just before 2012, and in February 2012 Valim’s company, Plataformatec, agreed to sponsor it. v0.5.0, the first release of the rewritten language, came out on 25 May 2012, and Elixir 1.0 followed on 18 September 2014 after 8,005 commits by 189 contributors. A decade later the team began adding a type system: v1.17 in June 2024 brought the first gradual set-theoretic types.

Why it’s built this way

Stay fully compatible with Erlang
The first version needed wrappers for every Erlang module and could never keep up. The rewrite calls Erlang code directly, so the whole Erlang/OTP ecosystem works from Elixir unchanged.
Run on the Erlang VM instead of building a new runtime
The Erlang VM was already known for running low-latency, distributed and fault-tolerant systems. Building on it gave Elixir that runtime, and its libraries, for free.
Gradual types inferred from existing code
Adding mandatory annotations would break a decade of dynamically typed code. Set-theoretic types inferred from patterns let the compiler find bugs without requiring changes to existing software.

Timeline

  1. 2011

    José Valim makes the first commit on 9 January

  2. 2012

    v0.5.0, the rewritten language, released on 25 May

  3. 2014

    Elixir 1.0 released on 18 September

  4. 2024

    v1.17 introduces gradual set-theoretic types in June

Sources12 · facts checked 8 October 2026

Improve this page on GitHub