Gleam OTP – Développement de programmes multicœurs tolérants aux pannes basés sur les acteurs

 (github.com/gleam-lang)
1 points par GN⁺ 2025-10-21 | 1 commentaires | Partager sur WhatsApp
  • Gleam OTP aide à développer des programmes dotés de tolérance aux pannes et de performances multicœurs en s’appuyant sur le modèle des acteurs
  • Il se distingue par son objectif de sécurité de type complète et de compatibilité avec Erlang OTP
  • Fournit des fonctions de reprise après incident et d’auto-réparation via des superviseurs
  • Ne propose qu’une partie des fonctionnalités d’Erlang/OTP, et des stratégies de gestion supplémentaires sont actuellement en cours de développement
  • Prend en charge différents types d’acteurs, dont les processus génériques, acteurs et superviseurs

Aperçu de Gleam OTP

  • Gleam OTP est un puissant framework d’acteurs inspiré de l’architecture OTP d’Erlang, adapté à l’implémentation de programmes multicœurs tolérants aux pannes
  • Il s’agit d’un projet open source distribué sous licence Apache-2.0

Principales caractéristiques et avantages

  • Garantit une sécurité de type complète pour les acteurs et messages
  • Offre une compatibilité avec Erlang OTP, ce qui facilite l’intégration avec des environnements Erlang existants
  • Assure la tolérance aux pannes via des superviseurs (supervisors), avec détection des défaillances, reprise automatique et gestion des arrêts
  • Vise des performances équivalentes à celles d’Erlang OTP
  • La documentation et les exemples fournis facilitent l’apprentissage et l’usage en production

Description par type d’acteur

  • Processus (process)

    • Sert de brique de base la plus fondamentale dans OTP
    • Constitue la base des autres types d’acteurs, mais est rarement utilisé directement dans une application Gleam

  • Acteur (actor)

    • Type de processus le plus couramment utilisé, offrant des fonctionnalités similaires à gen_server d’Erlang
    • Gère automatiquement les messages système OTP et active les fonctions de débogage et de traçage

  • Superviseur (supervisor)

    • Démarre d’autres processus et se charge de leur supervision et reprise
    • Redémarre automatiquement les processus enfants en cas de crash ou d’exception
    • Une composition imbriquée de superviseurs (supervision tree) permet de former la structure de tolérance aux pannes de l’application
    • Les détails d’implémentation sont disponibles dans la documentation de gleam/otp/static_supervisor et gleam/otp/factory_supervisor

Limites et problèmes

  • À l’heure actuelle, les acteurs ne prennent pas en charge tous les messages système OTP, et les messages non pris en charge sont ignorés
  • Certaines fonctionnalités de l’API de débogage OTP restent limitées
  • Si nécessaire, il est possible de demander la prise en charge de messages non implémentés en ouvrant une issue

Conclusion et importance du projet

  • Gleam OTP étend à Gleam les points forts de l’écosystème Erlang, ce qui lui donne une réelle importance en permettant de mettre en œuvre sécurité de type et tolérance aux pannes multicœur
  • Il convient aux applications où la stabilité et les performances sont essentielles en production
  • C’est un projet open source à forte valeur d’apprentissage et d’application pratique pour les startups, les développeurs IT spécialisés et les développeurs en général

À lire aussi

1 commentaires

 
GN⁺ 2025-10-21
Avis Hacker News
  • J’ai commencé un petit projet avec gleam/lustre, et jusqu’ici j’en suis vraiment très satisfait
    Si vous vous intéressez aux types statiques, à un environnement sans null, au fonctionnel et aux langages de la famille ML, je recommande d’essayer gleam
    Et bien sûr, ça tourne sur le BEAM
    • Je pense pareil
      Quand j’ai installé gleam, une cinquantaine de paquets se sont installés sur mon système, sans doute liés à Erlang/Elixir
      Je me demande ce qu’il en serait si on voulait seulement transpiler vers JS. C’est peut-être aussi un problème de packaging sur mon système
      Ce serait encore mieux s’il y avait Lua comme cible de transpilation. À mon avis, pour embarquer un DSL dans d’autres programmes, Lua est trois fois plus simple qu’un runtime JS
      Et surtout, le meilleur point jusqu’ici, c’est la communauté. La qualité des bibliothèques et des ressources de la communauté gleam est extrêmement élevée
      Ça me rappelle la communauté Rust : les problèmes difficiles ont déjà été traités par des gens brillants, donc on trouve facilement de bonnes solutions (lustre, squirrel, etc.)
      On y voit aussi beaucoup d’expérimentation et de créativité. Des choses qu’on remarque moins dans les grands écosystèmes de langage ressortent ici. Et à mesure que la communauté grandit, l’ambiance reste très accueillante
    • Tout ce que tu as mentionné m’intéresse. En revanche, je ne comprends pas encore vraiment BEAM ni OTP
      Vous recommandez de commencer par quoi pour apprendre ?
    • En partant de zéro sur tous les points cités, je me demande s’il vaut mieux apprendre d’abord gleam/lustre ou elixir/phoenix
  • Je me demande si les gens qui utilisent Gleam s’en servent aussi avec un framework web du type Phoenix
    J’essaie de me renseigner, parce que ce serait vraiment bien si on pouvait utiliser Gleam avec un framework comme Phoenix
    Je prépare actuellement un nouveau projet en Python, mais s’il existe une option crédible avec Gleam, j’aimerais bien essayer
    • Le développeur de Lustre a une vidéo de présentation où il montre une implémentation de fonctionnalités proches de LiveView avec Gleam/Lustre
      L’avantage, c’est qu’on peut décider très facilement ce qui relève du frontend et du backend
      Lien YouTube
    • Il n’existe pas encore de framework complet comme Phoenix, Django ou Rails
      En revanche, il y a des outils qu’on utilise souvent pour créer des web apps
      Lustre sert d’outil de vue de base, et Wisp joue le rôle du serveur
      Pour SQL, il y a squirrel et POG (récent, mais populaire)
  • PureScript est un langage de programmation fonctionnelle mature qui prend en charge un backend Erlang
    C’est une bonne option si vous cherchez une autre alternative statiquement typée sur le BEAM
    C’est un dialecte de Haskell, avec évaluation stricte et prise en charge du row polymorphism
    • Le backend JS de PureScript est mature, mais le backend Erlang et son écosystème restent très modestes par rapport à Gleam
    • Le site officiel et le dépôt GitHub disent seulement que PureScript compile vers JS ; je me demande d’où vient l’information sur le backend Erlang
  • Erlang/BEAM m’intéresse beaucoup, mais je n’ai jamais eu le temps de vraiment m’y mettre
    Je me demande comment c’est utilisé en pratique : est-ce qu’on construit toute la logique du service avec, ou seulement certaines parties ?
    • Je dirige une équipe et nous faisons une migration progressive vers Gleam
      Nous avons poussé le modèle « functional core, imperative shell » à l’extrême pour isoler Gleam afin qu’il gère les calculs lourds au sein d’une base de code Ruby on Rails existante
      Nous utilisons très peu les fonctionnalités OTP, et Rails reste concentré sur ses points forts naturels comme l’UI web et l’API HTTP
      Rails se charge de préparer les valeurs d’entrée des jobs, puis les données sont transmises à Gleam via Redis sous la forme d’un unique ensemble atomique de valeurs
      Nous avons créé un fin wrapper en Elixir qui ne gère que le réseau et les E/S fichier, tandis que la logique métier vit dans des modules Gleam
      Je compte bientôt écrire un article plus technique sur cette approche. C’est un sujet qui suscite souvent de l’intérêt sur HN
    • Chez TV Labs, nous utilisons Elixir pour toutes sortes de choses : services web, moteur de matching en temps réel, sandboxing de code Lua, communication avec des microcontrôleurs via un protocole binaire, machine learning, etc.
      Elixir est un excellent langage généraliste, avec des points forts dans de nombreux domaines
      Pour une discussion plus détaillée, voir ma vidéo Developer Voices
      Lien YouTube
    • Je recommande de venir discuter sur elixirforum.com
      Beaucoup de gens y construisent des systèmes sérieux entièrement avec Erlang/Elixir et le BEAM, donc si vous avez des questions, vous obtiendrez de bonnes réponses
    • J’ai vu les deux approches
      Une fois qu’on comprend suffisamment OTP, il devient naturel de tout construire dessus
      C’est ce que j’ai fait pendant 7 ans, mais j’ai aussi constaté qu’il faut du temps aux développeurs juniors pour se familiariser avec cet écosystème
  • Pour que Gleam soit pris plus au sérieux, je pense qu’il vaudrait mieux éviter d’afficher des messages politiques forts sur la page du projet
    Je ne vois pas l’intérêt d’ajouter des sujets politiques sur la page d’un projet technique
    Ce n’est pas une question d’être d’accord ou non : à mon avis, dans un cadre professionnel, il vaut mieux laisser ce genre de débat de côté
    Sinon, la discussion se détourne inutilement du sujet
    • Tu parles de la phrase : « Black lives matter. Trans rights are human rights. No nazi bullsh*t. »
      Celle qui n’apparaît qu’une seule fois en bas de la page ?
      Si quelqu’un décide de ne pas utiliser le projet à cause de cette seule ligne, alors j’ai l’impression que cela fonctionne exactement comme prévu
    • Tu dis que « la discussion se détourne inutilement du sujet »
      Mais en pratique, c’est justement toi qui l’as détournée
  • À mes yeux, le modèle des acteurs pose des problèmes de calcul distribué dès qu’il faut partager des informations entre processus
    Pour la tolérance aux pannes et le multicœur, je trouve préférable d’utiliser de la mémoire transactionnelle logicielle et un système d’effets fonctionnels comme Scala/ZIO
    Cela dit, on peut toujours utiliser le modèle des acteurs quand c’est pertinent
    Et si l’on regarde la maturité de l’écosystème JVM, l’observabilité et le niveau de préparation pour la production, il est supérieur au BEAM
    • Je trouve que c’est un point de vue assez atypique
      Je comprends qu’on critique les faiblesses du BEAM, mais s’attaquer à ses points forts me paraît étrange
      Le BEAM repose sur l’échange de messages immuables entre green threads légers et peu coûteux
      Il dispose d’un système de supervision robuste, donc pas besoin de s’inquiéter des data races ni des blocages de threads
      Tout cela est intégré nativement, sans boilerplate
      Grâce à l’immuabilité, les performances sont aussi étonnamment bonnes
      Au final, le BEAM est la plateforme la plus optimisée pour la tolérance aux pannes et les systèmes distribués/concurrents
    • Un point qui n’avait pas été mentionné : Erlang (la base de gleam) est un langage qui a permis d’atteindre 99,9999999 % de disponibilité
      Une grande partie de cette robustesse vient de son infrastructure de supervision solide et inter-machine
      C’est un langage qui a fortement inspiré l’émergence des systèmes d’acteurs
      Littéralement, Erlang existe pour faire cela, et il le fait extrêmement bien
    • Tu disais que « le modèle des acteurs a du mal avec le partage entre processus », mais en réalité le modèle des acteurs fonctionne soit par copie des données, soit par transfert de propriété via passage de messages
      Si des données doivent réellement être partagées, elles doivent alors impérativement être immuables
    • Je serais curieux d’avoir un exemple de situation où on ne peut pas transmettre des données mutables sous forme de structures immuables
      Le seul cas qui me vient à l’esprit, c’est du calcul numérique extrêmement intensif, et dans ce cas on ne l’écrit pas directement en elixir ou en erlang : on l’implémente en NIF
    • Avec Elixir/Gleam/OTP, les programmes sont tous un ensemble de processus indépendants
      Même sans utiliser explicitement le pattern actor, la transmission d’état et la coordination sont déjà des problèmes résolus
      Il y a déjà toutes les primitives de base : tasks, agents, GenServer, Supervisor, etc.