Retour d’expérience sur l’utilisation de Gleam pour Advent of Code

• Les énigmes des 12 jours d’Advent of Code 2025 ont été résolues en Gleam, et les messages d’erreur au niveau de Rust ainsi que le style fonctionnel centré sur les pipelines ont été particulièrement impressionnants
• Des fonctions intégrées comme echo, fold_until et list.transpose simplifient le débogage et la résolution de problèmes de composition, tandis que la sécurité fondée sur les types optionnels s’avère utile pour traiter les énigmes sur grille
• L’absence de file IO et de fonctionnalités de regex dans la bibliothèque standard, les contraintes du pattern matching sur les listes et les syntaxes de comparaison explicites sont signalées comme des points inconfortables à l’usage répété
• Les différences de gestion des entiers entre la machine virtuelle Erlang et la cible JavaScript ont rendu nécessaire l’usage de bigi, et certaines énigmes ont été résolues en appelant des outils externes (glpsol)
• Globalement, le passage à une manière de penser fonctionnelle a rendu la résolution plus claire, et l’auteur exprime l’envie d’appliquer Gleam à de vrais projets (par exemple, le développement d’un serveur web)

---

Advent of Code 2025 et le choix de Gleam

• L’auteur, qui termine Advent of Code chaque année, a choisi cette fois le langage Gleam pour résoudre les énigmes sur 12 jours
  • L’événement de cette année a été réduit à 12 jours au lieu de 25, et bien que chaque problème ait été difficile, la structure se prêtait bien à l’apprentissage
• Le rythme des énigmes étant rapide et des problèmes complexes apparaissant avant que l’outillage ne soit complètement prêt, cela a constitué un environnement idéal pour apprendre un nouveau langage

Les atouts du langage Gleam

• Il se distingue par une syntaxe concise, des messages d’erreur du compilateur utiles et un retour très pédagogique, au niveau de Rust
• Le style fonctionnel centré sur l’opérateur de pipeline correspond bien à la structure des problèmes d’AoC (parsing → transformation → fold)
• L’extension Gleam pour IntelliJ et le LSP ont fonctionné de manière stable, rendant l’environnement de développement agréable
• La programmation fonctionnelle (FP), par rapport au code impératif, pousse à décrire l’essence du problème plutôt qu’à raisonner en étapes procédurales

Fonctions marquantes et exemples d’usage du code

• echo : une simple fonction d’affichage qui permet de vérifier une valeur au milieu d’un pipeline, utile pour déboguer sans formatage de chaîne
  • L’absence d’interpolation de chaînes est toutefois mentionnée comme un inconvénient, car elle oblige à multiplier les opérations <>" lors de la génération de texte
• Type optionnel (dict.get) : permet une exploration sûre des voisins dans les énigmes sur grille, sans vérifications manuelles de bordure
• Utilitaires de liste
  • list.transpose : l’opération de transposition de matrice simplifie la structure de certaines énigmes
  • list.combination_pairs : génère des paires de points 3D en une ligne, sans boucles imbriquées
  • fold_until : une fonction de fold capable de s’arrêter dès qu’une condition est satisfaite, efficace pour les calculs itératifs des énigmes

Contraintes et points d’inconfort de Gleam

• Pas de file IO dans la bibliothèque standard, remplacé par le package simplifile
• Les fonctionnalités de regex nécessitent aussi une dépendance externe (gleam_regexp)
• Contraintes du pattern matching sur les listes : la forme [first, ..middle, last] n’est pas possible
• Gestion explicite des comparaisons : il faut utiliser le type order, ce qui alourdit la syntaxe pour des comparaisons simples

Usages avancés et cas par énigme

• bigi : utilisé pour éviter les dépassements d’entiers sur la cible JavaScript
• Bitmask XOR : dans le Day 10-1, le problème de basculement des lumières est modélisé avec une opération XOR pour une résolution efficace
• Appel à glpsol : dans le Day 10-2, un fichier LP est généré puis une commande externe est exécutée pour résoudre un système d’équations linéaires
• Clé de mémoïsation : dans le Day 11-2, nœud et état sont utilisés ensemble comme clé pour obtenir le résultat immédiatement
• La dernière énigme dépendait d’hypothèses sur l’entrée et a été résolue par une simple comparaison d’aire (heuristic_area <= max_area)

Conclusion et suite

• Malgré les limites de sa bibliothèque standard, Gleam montre de vraies forces en sécurité et en expressivité
• Les pipelines, les types option/result, les fonctions de liste et fold_until rendent la résolution d’énigmes plus claire
• L’auteur prévoit de l’utiliser dans de vrais projets comme le développement de serveurs web, et indique vouloir continuer à utiliser Gleam pour Advent of Code l’année suivante
• L’intégralité du code source est publiée dans le dépôt GitHub (tymscar/Advent-Of-Code/2025/gleam/aoc/src)

[GN⁺]

Commentaires sur Hacker News

• Gleam est vraiment un magnifique langage. J’aimerais qu’Elixir évolue dans cette direction du point de vue du système de types
  Gleam fonctionne aussi sur la VM Erlang, BEAM, ce qui rend la concurrence et le traitement des files d’attente très simples
  L’écosystème est excellent aussi. En revanche, je m’inquiète du fait qu’après l’ère des LLM, l’évolution des langages semble s’être arrêtée depuis 2021
  Cela dit, Gleam est arrivé juste avant que cette porte ne se ferme, et j’espère que les LLM vont bientôt le rattraper

  • Je me demande pourquoi tu penses que les LLM freinent l’évolution des langages. Les modèles récents incluent des connaissances allant jusqu’à cette année, et ils apprennent plutôt bien un nouveau langage avec seulement quelques exemples
    Comme les langages ne peuvent pas être totalement différents en termes de syntaxe ou de philosophie, je ne pense pas que ce soit un gros problème
  • Dire que Gleam a été construit sur OTP n’est pas tout à fait exact. La VM Erlang, c’est BEAM, et OTP est un ensemble de bibliothèques et de principes de conception d’Erlang
    Gleam fournit de son côté un sous-ensemble d’OTP sûr du point de vue des types. Voir la bibliothèque associée : gleam-lang/otp
  • Oui, la VM Erlang est BEAM, pas OTP. L’implémentation d’OTP dans Gleam n’est pas encore aussi aboutie que celle d’Elixir ou d’Erlang
  • J’ai moi aussi récemment réalisé mon premier projet en Elixir avec des fonctionnalités LLM, et j’ai plutôt l’impression que cette tendance pourrait favoriser l’adoption des langages
  • Elixir introduit lui aussi progressivement le set-theoretic typing. Documentation associée : gradual-set-theoretic-types

• J’ai fait l’Advent of Code de cette année en Gleam, et j’ai été assez impressionné
  Côté points forts, les performances sont bonnes, et le serveur de langage est étonnamment puissant. Formatage automatique, import automatique, complétion du pattern matching : l’expérience de développement est excellente
  Côté points faibles, le formateur étire trop le code à la verticale et, comme la simplicité est privilégiée, on répète souvent des choses comme list.map. Et puis l’écosystème de bibliothèques est encore limité

  • Moi aussi, j’ai été surpris par les performances. Ce n’est pas du niveau du C, mais c’est bien plus rapide que ce à quoi je m’attendais. Le serveur de langage fonctionne aussi très bien dans presque tous les IDE
    On peut raccourcir list.map avec import gleam/list.{range, map}. Le portage de bibliothèques C pourrait aussi être intéressant
  • Ces défauts restent supportables, mais l’absence de if/else et de guard est gênante. Les branchements booléens deviennent trop verbeux
  • J’ai fait AoC en F#, et j’ai eu une impression similaire. La répétition d’espaces de noms comme List.map nuit à la découvrabilité
  • Le formatage des arguments vient probablement de l’algorithme de Prettier. Cela dit, je trouve quand même que c’est bien mieux que le binpacking de clang-format

• J’aime bien Gleam, mais je regrette les limitations sur les appels de fonctions récursifs. Les appels de fonctions internes ne sont pas totalement libres
  Syntaxiquement, c’est moins élégant que Scheme, et conceptuellement plus simple qu’Erlang. Mais le typage statique reste un atout
  J’ai aussi utilisé OCaml, mais la reproductibilité de l’environnement était moins bonne à cause de problèmes comme les lock files d’opam. Je me dis souvent que ce serait bien si l’écosystème SML était plus développé

  • Je pense à peu près la même chose. Haskell est théoriquement superbe, mais même un simple hello world consomme beaucoup de ressources
    Idris 2 a des types dépendants et une conception élégante, mais son écosystème est petit, et PureScript est plus pratique que Haskell tout en restant lié au runtime JS
  • Si tu aimes la famille ML, je recommande ReScript v12. C’est un bon équilibre entre OCaml et Gleam

• En voyant la fonctionnalité echo, je me suis dit que j’aimerais qu’un débogueur propose nativement ce genre de visualisation des résultats intermédiaires
  Ce serait bien de pouvoir voir le résultat intermédiaire d’un slice de tableau ou d’une chaîne de filtres sans modifier le code
  Je pense aussi qu’utiliser des tableaux 2D comme grille est inefficace. Un tableau 1D + des informations de limites est plus sûr et plus efficace

• Je ne connais pas très bien Gleam, mais list.map(fn(line) { line |> calculate_instruction })
  ne pourrait-il pas simplement s’écrire list.map(calculate_instruction) ?

  • Oui, exactement, il m’arrive souvent de faire un traitement plus complexe puis de le supprimer, en laissant cette forme derrière moi
  • Oui, c’est bien ça

• Gleam est un excellent langage. Il ne m’a pas particulièrement marqué, mais ça fait plaisir de voir que des gens l’apprécient
  Je me dis que la combinaison Gleam + Lustre pourrait devenir le nouvel Elm

  • En tant que développeur backend, Elm m’attirait, mais je m’en suis éloigné à cause des conflits avec son créateur et de l’arrêt des releases. Malgré ça, son architecture m’a été utile dans d’autres projets
  • J’ai moi aussi récemment créé une petite appli avec Gleam + Lustre, et ça s’est bien mieux passé qu’avec Elm + PostgREST. Je compte maintenant l’utiliser pour des projets plus ambitieux
  • J’ai regardé Lustre, mais l’écosystème est encore petit. Il n’y avait même pas d’exemple lié à l’authentification, donc je suis parti sur LiveView. Cela dit, l’ergonomie est bonne, donc j’espère que ça va se développer

• En ce moment, à l’ère des LLM, je me demande s’il vaut encore la peine d’apprendre un nouveau langage
  Si le LLM n’a pas été entraîné sur ce langage, j’ai peur que son utilité en tant qu’outil soit réduite

  • À long terme, si les LLM ne sont pas capables d’apprendre de nouveaux langages, alors ils auront échoué dans leur objectif d’intelligence générale
  • Il y a un ou deux ans, cette inquiétude existait, mais aujourd’hui Claude Code écrit déjà assez bien de l’Elixir. Même avec peu de données d’entraînement, ce n’est pas un problème
  • Claude gère aussi bien Gleam. La documentation et la qualité des messages de diagnostic facilitent l’apprentissage pour les LLM. On est au niveau de Rust pour les diagnostics
    À l’inverse, Swift est plus difficile à manipuler pour les LLM à cause de la complexité de sa syntaxe
  • Si l’on considère un langage comme un outil, le manque de demande sur le marché peut être une contrainte plus importante
  • J’espère que les nouveaux langages ne vont pas s’arrêter à cause des limites des LLM

• Quand j’avais regardé Gleam il y a quelque temps, j’avais l’impression qu’il n’y avait pas de dispatch dynamique (interface ou type class). Je me demande où ça en est aujourd’hui

  • En général, on résout ça en disant « passe une structure de fonctions ». C’est une approche explicite qui a même l’avantage d’éviter la complexité des génériques
  • Gleam prend en charge les fonctions de première classe, donc le dispatch dynamique est possible. Les type classes ou interfaces peuvent au final se ramener à des fonctions d’ordre supérieur

• [first, ..rest] ou [first, second] sont possibles, mais pas [first, ..middle, last].
  C’est probablement bloqué volontairement parce que trop coûteux

• Heureusement, la police des titres de blog est arrivée rapidement sur les lieux
  Lien associé