Le modèle de concurrence d'Elixir

Elixir est construit sur la VM Erlang (BEAM), qui a été conçue dès le départ pour supporter une concurrence massive, des systèmes tolérants aux pannes et une haute disponibilité — des qualités qui deviennent non négociables dans les services web modernes, les applications en temps réel et les plateformes distribuées.

À mesure que les applications s'étendent sur les cœurs, les nœuds, et même les centres de données, les processus légers d'Elixir et son modèle de passage de messages permettent aux développeurs de gérer la concurrence naturellement, sans la complexité des modèles traditionnels de threading.

Ses arbres de supervision rendent les applications auto-réparatrices et résilientes par conception — une caractéristique vitale pour les systèmes qui nécessitent un temps d'arrêt quasi nul, comme les plateformes de messagerie, les backends IoT et les applications fintech.

En se tournant vers l'avenir, la tendance vers des systèmes décentralisés et réactifs (edge computing, coordination IA, tableaux de bord en direct) joue directement en faveur des forces d'Elixir — le positionnant comme l'un des choix les plus pérennes pour les logiciels évolutifs et concurrents.

Au cœur d'Elixir se trouve BEAM — la machine virtuelle Erlang — conçue spécifiquement pour exécuter simultanément des milliers à des millions de processus légers.

Contrairement aux threads traditionnels du système d'exploitation, les processus BEAM sont extrêmement légers et isolés : ils ne partagent pas de mémoire et communiquent uniquement via des passages de messages. Ce modèle élimine des classes entières de bugs de concurrence tels que les race conditions et les blocages.

Chaque processus s'exécute dans un environnement planifié de manière préemptive avec son propre tas et sa propre pile. BEAM planifie ces processus en `petites réductions` (unités d'exécution) et garantit l'équité, permettant des systèmes réactifs même sous forte charge.

Cette architecture permet également le remplacement à chaud du code, permettant de mettre à jour des parties du système en production sans arrêter l'application — un avantage crucial pour les systèmes qui nécessitent une disponibilité continue.

Voici un exemple de création de milliers de processus dans Elixir — un modèle courant, grâce à l'efficacité de BEAM.

      
        
for i <- 1..10_000 do
  spawn(fn -> IO.puts("Hello from process #{i}") end)
end

      
    

Chaque appel à `spawn/1` crée un nouveau processus en moins de temps et avec moins de mémoire qu'un thread typique. Ces processus sont entièrement gérés par BEAM, offrant isolation des pannes, parallélisme et évolutivité.

Bien qu'Elixir permette de créer des processus bruts en utilisant `spawn/1`, il offre également de puissantes abstractions comme `GenServer` pour construire des systèmes concurrents robustes avec une structure claire.

Un `GenServer` est un processus serveur générique — un module de comportement fourni par Elixir qui vous aide à encapsuler l'état, gérer les messages et gérer des opérations synchrones ou asynchrones.

Il abstrait le code standard de passage de messages et encourage une architecture cohérente. En utilisant `GenServer`, les développeurs peuvent se concentrer sur la logique de l'application tout en s'appuyant sur des modèles éprouvés pour la fiabilité et la supervision.

Voici un exemple minimal d'implémentation d'un GenServer :

      
        
defmodule Counter do
  use GenServer

  # Client API
  def start_link(initial_value) do
    GenServer.start_link(__MODULE__, initial_value, name: __MODULE__)
  end

  def increment do
    GenServer.cast(__MODULE__, :increment)
  end

  def get do
    GenServer.call(__MODULE__, :get)
  end

  # Server Callbacks
  def init(initial_value) do
    {:ok, initial_value}
  end

  def handle_cast(:increment, state) do
    {:noreply, state + 1}
  end

  def handle_call(:get, _from, state) do
    {:reply, state, state}
  end
end

      
    

Ce module `Counter` démarre un processus avec une valeur initiale, permet de l'incrémenter de manière asynchrone via `cast`, et de récupérer la valeur actuelle avec `call`.

L'utilisation de GenServer favorise un code concurrent tolérant aux pannes et bien organisé, en particulier lorsqu'il est combiné avec les arbres de supervision d'Elixir.

Le modèle de concurrence d'Elixir n'est pas seulement théoriquement solide — il résout de vrais problèmes à grande échelle. Grâce à BEAM et aux abstractions comme GenServer, Elixir excelle dans la construction de systèmes hautement disponibles, tolérants aux pannes et concurrents par défaut.

Voici quelques exemples concrets où Elixir brille :

• Applications de chat : Les processus sont légers et isolés, rendant Elixir idéal pour gérer des milliers d'utilisateurs simultanés. Les Phoenix Channels rendent la communication en temps réel triviale.
• IoT et télémétrie : Elixir gère efficacement de grands volumes de données entrantes, avec des GenServers qui maintiennent l'état et traitent en parallèle.
• Traitement en arrière-plan : Des bibliothèques comme Oban utilisent GenServer et les arbres de supervision pour gérer de manière fiable les files d'attente de tâches, les nouvelles tentatives et la planification.
• APIs à grande échelle : Grâce à la VM Erlang sous-jacente, les applications Elixir gèrent un débit élevé avec une faible latence, même sous forte charge.

Par exemple, Discord a initialement utilisé Elixir pour réduire la latence et améliorer la fiabilité pour des millions de connexions vocales simultanées. Elixir les a aidés à simplifier la complexité sans sacrifier les performances.

Que vous construisiez un backend SaaS évolutif, une application en temps réel ou un pipeline de traitement, Elixir fournit les outils pour garder les choses simples et résilientes.

L'une des forces principales de BEAM est sa philosophie de « laissez-le planter » (let it crash). Au lieu d'essayer de prévenir chaque défaillance possible, Elixir encourage l'écriture de petits processus isolés qui peuvent échouer en toute sécurité — puis être automatiquement redémarrés. C'est là que les Superviseurs entrent en jeu.

Un Superviseur est un processus spécial dont le travail est de surveiller et redémarrer les processus enfants lorsqu'ils échouent. Cette conception favorise la haute disponibilité et l'isolation des pannes en garantissant que les défaillances sont contenues et automatiquement récupérées.

      
        
defmodule MyApp.Worker do
  use GenServer

  def start_link(_args) do
    GenServer.start_link(__MODULE__, %{}, name: __MODULE__)
  end

  def init(state), do: {:ok, state}
end

defmodule MyApp.Supervisor do
  use Supervisor

  def start_link(_init_arg) do
    Supervisor.start_link(__MODULE__, :ok, name: __MODULE__)
  end

  @impl true
  def init(:ok) do
    children = [
      {MyApp.Worker, []}
    ]

    Supervisor.init(children, strategy: :one_for_one)
  end
end

      
    

Dans cet exemple, MyApp.Supervisor démarre un GenServer MyApp.Worker. Si ce worker plante, le superviseur le redémarre automatiquement, en utilisant la stratégie :one_for_one. D'autres stratégies incluent :one_for_all et :rest_for_one, selon la relation entre les processus.

Les arbres de supervision sont des structures hiérarchiques de superviseurs et de workers, formant un système résilient où les erreurs localisées ne font pas tomber l'ensemble de l'application.

Avec les arbres de supervision, les applications Elixir récupèrent élégamment des défaillances d'exécution, ce qui les rend idéales pour les systèmes qui nécessitent une haute disponibilité, comme les plateformes bancaires, les services de messagerie et les applications web distribuées.

Au cœur de chaque projet Elixir se trouve une application OTP — une façon standardisée d'empaqueter, configurer et exécuter un système Elixir. Une application OTP est plus qu'un module ou un ensemble de fonctions : c'est une unité autonome de comportement qui définit comment votre application démarre, supervise ses processus et s'intègre avec d'autres applications.

Une application OTP définit généralement un arbre de supervision et est démarrée par le runtime BEAM au démarrage de votre projet. Ce modèle vous permet de structurer votre code en composants modulaires et résilients, idéaux pour les services de longue durée comme les serveurs web, les files d'attente de messagerie ou les processeurs de tâches en arrière-plan.

      
        
defmodule MyApp.Application do
  use Application

  @impl true
  def start(_type, _args) do
    children = [
      {MyApp.Worker, []}
    ]

    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

      
    

Le module MyApp.Application définit le point d'entrée de votre application. Une fois déployé, ce module garantit que votre système démarre de manière prévisible et tolérante aux pannes en utilisant l'arbre de supervision.

Applications OTP dans les systèmes distribués

Les applications OTP peuvent facilement être combinées et déployées sur plusieurs nœuds dans un système distribué. Avec la communication de nœud à nœud, vous pouvez évoluer horizontalement et déléguer des tâches entre différentes machines physiques ou virtuelles.

Par exemple, un cluster d'applications OTP peut coordonner le travail entre les nœuds, équilibrer la charge ou récupérer après des défaillances partielles — faisant d'Elixir un choix puissant pour construire des systèmes distribués, des microservices et des API disponibles mondialement.

Utilisé dans les systèmes de production

Les serveurs web Phoenix, les plateformes de traitement de tâches comme Oban et les systèmes de chat utilisent tous des applications OTP en coulisse. Chaque application encapsule sa logique, ses dépendances et ses arbres de supervision, les rendant faciles à composer et à maintenir.

Cette modularité est l'une des raisons pour lesquelles les systèmes Elixir sont considérés comme faciles à comprendre — même lorsqu'ils évoluent pour servir des millions d'utilisateurs.

La force d'Elixir réside dans son modèle de concurrence, sa conception tolérante aux pannes et sa capacité à évoluer efficacement pour les applications distribuées à forte intensité d'E/S. Cependant, il est important de comprendre qu'Elixir — fonctionnant sur BEAM — n'est pas optimisé pour les calculs intensifs bruts du CPU.

Pour gérer les opérations critiques en termes de performance, de nombreuses équipes combinent Elixir avec du code natif écrit en Rust ou C. L'un des exemples les plus célèbres est Discord, qui a remplacé certaines parties de sa pile Elixir par des composants basés sur Rust pour améliorer les performances, tout en conservant les avantages d'Elixir pour le reste du système.

      
        
# Example: calling Rust from Elixir using Rustler
defmodule Math.NIF do
  use Rustler, otp_app: :my_app, crate: "native_math"

  def add(_a, _b), do: :erlang.nif_error(:nif_not_loaded)
end

      
    

Grâce à des outils comme Rustler ou les NIFs (Native Implemented Functions), vous pouvez trouver un équilibre : garder votre logique métier et votre résilience dans Elixir, tout en déchargeant la logique la plus gourmande en CPU vers du code natif.

Perspectives : Phoenix et le Web

Cet article s'est concentré sur les fondements d'Elixir et de BEAM, mais il y a encore plus de puissance qui attend dans l'écosystème Elixir. Le framework Phoenix s'appuie sur ces concepts pour fournir une plateforme de développement web complète et évolutive.

Dans un prochain article, nous plongerons dans Phoenix, LiveView, et comment Elixir permet de créer des applications web interactives en temps réel — avec moins de JavaScript et plus de fiabilité.