Elm 0.19.2 améliore la vitesse de build

• Elm 0.19.2 est la première étape d’une série de petites releases visant à intégrer des améliorations du compilateur avant Elm 1.0
• Sur une grande base de code Elm, la compilation depuis zéro a été mesurée à 5,7 secondes, puis les builds incrémentaux à moins de 350 ms, ce qui réduit le risque d’interrompre le flux de concentration pendant le développement
• Cette amélioration s’est concentrée sur la réduction des allocations pendant le parsing ; dans une expérimentation sur 850 000 lignes, on a observé une baisse de 20 % du volume copié par le GC, une baisse de 10 % du pic d’utilisation mémoire et une amélioration globale de 7 % de la vitesse
• Lors de tests sur des projets réels, l’ampleur des gains a varié ; un cas compilant 351 modules depuis zéro est passé de 4,981 secondes à 2,595 secondes, soit 1,9 fois plus rapide
• Les idées de performance et de langage issues du travail sur Acadia seront intégrées progressivement dans des releases sans rupture de compatibilité, puis mèneront à Elm 1.0 après les dernières finitions

---

Compilation plus rapide dans Elm 0.19.2

• Elm 0.19.2 est la première release à intégrer par petites touches les améliorations du compilateur accumulées dans Elm
• Un compilateur rapide réduit les situations où les développeurs passent à un onglet du navigateur et perdent leur concentration
  • Quand la compilation incrémentale est inférieure à 400 ms, il n’y a presque plus d’occasion de passer à autre chose
• Les performances sur 850 000 lignes de code Elm sont les suivantes
  • Compilation depuis zéro : 5,7 secondes
  • Build incrémental : moins de 350 ms
• Le changement réel s’est concentré sur la réduction des allocations pendant le parsing
  • Volume copié par le GC réduit de 20 %
  • Pic d’utilisation mémoire réduit de 10 %
  • Vitesse globale améliorée de 7 %
• Pour les programmes de plus de 500 000 lignes, on peut s’attendre à une amélioration modérée ; pour les programmes plus petits, le compilateur Elm reste très rapide
• Dans les tests en conditions réelles, les gains ont varié selon les projets
  • Certains projets ont connu une légère amélioration
  • Dans un cas compilant 351 modules depuis zéro, le temps est passé de 4,981 secondes à 2,595 secondes, soit une amélioration de 1,9 fois
• La nouvelle version est disponible sur la release Elm compiler 0.19.2

Les prochaines releases vers Elm 1.0

• Des idées issues d’un travail sur le compilateur lié aux bases de données, appelé Acadia, devraient aussi être utilisées dans Elm
  • Acadia est actuellement en alpha privée
  • Le partage public est prévu pour la fin de l’année
• Les idées à intégrer dans Elm couvrent à la fois des améliorations de performance et des fonctionnalités du langage
  • Exemple : un parser plus rapide
  • Exemple : les types equatable, hashable
• Ces changements devraient être intégrés sous la forme d’une série de petites releases sans rupture de compatibilité, afin de s’insérer naturellement dans Elm
• Lors de la phase de finition finale, le projet prévoit de passer à Elm 1.0
• Les utilisateurs qui découvrent Elm peuvent commencer avec les exemples en ligne et le guide
• Elm 0.19.2 étant une release de patch, les projets existants peuvent télécharger la nouvelle version et l’utiliser immédiatement

[GN⁺]

Avis sur Hacker News

• Aujourd’hui, je vois plutôt Elm comme un langage de recherche très influent
  Il a un cap très clair, mais pas de feuille de route publique ni de support officiel, et sa direction ne semble guère intéressée par la construction d’une communauté ou d’une core team
  Cela dit, l’expérience de travail est vraiment excellente, et cela a donné naissance à plusieurs forks et projets dérivés. Lors de la récente conférence Gleam, Louis Pilfold a plaisanté en disant que « les utilisateurs d’Elm maintiennent chacun leur propre compilateur » ; en pratique, il y en a au moins 6, et 2 autres ont encore été annoncés le mois dernier
  C’est encourageant de voir Evan avancer vers une 1.0, et j’aimerais qu’après avoir qualifié Elm de « terminé », l’un des projets successeurs puisse se charger du travail difficile consistant à réunifier les forks et à développer la communauté
  Personnellement, si je cherche ensuite quelque chose dans l’esprit d’Elm, je regarderai Gleam + Lustre. Le duo mainteneurs qui se soucient de la communauté et de la conception me paraît prometteur, et ça fonctionne à la fois côté frontend et backend

  • La trajectoire d’Elm a été assez étrange, mais le qualifier de langage de recherche me semble juste
    À une époque, il était évangélisé avec enthousiasme, il y avait beaucoup de billets de blog et de présentations, ainsi qu’un engouement et une adoption notables
    Puis son auteur a pratiquement disparu et le projet s’est figé
    Bien sûr, c’est son projet, donc il en a le droit, mais je pense que les attentes auraient dû être mieux cadrées dès le départ. L’évangélisation active a aidé à diffuser les idées, mais elle a aussi donné aux développeurs l’impression d’avoir été soudainement abandonnés
  • Le meilleur aspect d’Elm, c’est qu’il donne fortement une impression à la Haskell. Il y a quelques années, j’ai construit des choses amusantes avec Elm
    Le deuxième meilleur aspect, c’est la philosophie « si ça compile, ça marche ». Honnêtement, on retrouve une sensation similaire dans une grande partie de Rust. C’est moins Haskell, mais il y a tout de même l’ombre chaleureuse de ses ancêtres fonctionnels
  • Gren m’a semblé être un successeur tout à fait capable, avec une communauté active et prête à aider
  • J’en fais partie. J’ai étendu le langage pour y ajouter plusieurs fonctionnalités pratiques et, en substance, le faire prendre en charge un canal d’erreurs approprié et l’injection de dépendances via des types somme effaçables
    Elm est un bon langage, mais Evan ne semble pas vraiment intéressé par la création de quelque chose de véritablement utile, et la gouvernance du langage dans son ensemble est chaotique
  • Je pense que les gens sont déçus par la stagnation d’Elm précisément parce qu’Elm est tellement bon. Mais cette stagnation est aussi l’une des raisons pour lesquelles Elm est bon

• En 2023, j’ai écrit un billet expliquant pourquoi j’utilisais encore Elm
  https://taylor.town/elm-2023
  Aujourd’hui, en 2026, je continue à utiliser Elm pour les mêmes raisons :)
  En bonus, Claude semble très bien s’accorder avec Elm
  https://taylor.town/diggit-000

• Il y a environ 2 ans, j’ai fait une expérience de vibe coding avec ChatGPT en créant un jeu Snake pour navigateur dans Elm, mon langage préféré
  À l’époque, c’était encore assez brut, et j’en avais conclu que les grands modèles de langage pourraient bien tuer Elm
  Aujourd’hui, j’utilise Elm en production, et les grands modèles de langage se sont beaucoup améliorés. Au contraire, je pense qu’Elm est désormais un langage idéal pour les grands modèles de langage, au point que cela pourrait accroître son adoption. Il est plus simple que la plupart des langages, stable, et intègre dans le langage une architecture très prescriptive, ce qui rend les bases de code très similaires entre elles

  • Grâce à l’IA, je me suis aussi davantage plongé dans la musique, j’ai acheté un clavier MIDI et configuré un vrai logiciel de DAW
    Je construis aussi davantage de choses en Rust et je lis plus de documentation Rust. Les grands modèles de langage ne doivent pas servir d’excuse pour ne pas apprendre le sujet sur lequel on les utilise ; sinon, on est un mauvais ingénieur
    Les grands modèles de langage font gagner du temps pour enquêter et apprendre, afin de pouvoir maintenir ce qu’ils produisent. Et quand on comprend le problème, on rédige aussi de meilleurs prompts
  • Dire que les grands modèles de langage pourraient augmenter l’adoption d’Elm est à la fois vrai et faux
    Au final, tout dépend de la quantité d’Elm présente dans les données d’entraînement et le RLHF. Je suis d’accord pour dire que les frameworks ou langages structurés rendent la génération plus facile, car les bases de code se ressemblent davantage
    Mais cela ne suffit pas ; l’adoption par les développeurs est généralement un débat bien plus complexe en soi
  • Les choses se sont peut-être améliorées, mais j’ai été très déçu de voir des agents comme Claude Code trébucher constamment sur les espaces significatifs d’Elm
    Cela m’a paru étrange, car il s’en sort très bien avec Python, et Elm fait partie des langages modernes les plus stables. Il est même tellement stable que certains se plaignent qu’il ne change pas. Cela dit, mon dernier essai remonte à environ un an, donc j’imagine que ça s’est amélioré depuis
  • Ce point de vue est valable. Je n’y avais jamais pensé comme ça, mais si l’écosystème n’avance pas, je resterais tout de même hésitant

• Les limitations liées à JavaScript ont-elles été résolues ? Dans mon souvenir, pour interagir avec JavaScript, il fallait utiliser le mécanisme des Ports d’Elm, et il me semble qu’il n’était pas possible d’écrire directement des wrappers
  Il me semble aussi qu’il y avait eu une controverse quand quelqu’un avait forké le projet pour permettre d’écrire directement des wrappers JavaScript ou une FFI

  • La FFI passe encore principalement par les ports. Côté vue, on utilise parfois des Web Components
    C’est un choix intentionnel, et il est très probable qu’il soit maintenu jusqu’à la 1.0, et même au-delà

• Je ne savais pas que ce projet était encore vivant. Ce n’est pas pour être sarcastique, mais je pensais qu’il était déjà terminé.

  • Le projet était mort. La version précédente datait d’il y a 7 ans, et après l’arrêt de la maintenance par son créateur, la communauté n’a pas réussi à dépasser le modèle BDFL, donc tout est resté figé.
    Il était donc mort, et il vient tout juste de ressusciter. Entre-temps, j’imagine que la communauté s’est beaucoup étiolée.
  • Je n’étais pas profondément impliqué dans la communauté, mais je connaissais des gens qui y participaient à l’époque, et d’après ce que j’ai compris, la suppression des opérateurs infixes personnalisés lui a fait perdre beaucoup de soutien dans la communauté.
    C’était une fonctionnalité très populaire, mais elle a été supprimée parce que le créateur du langage ne l’aimait pas, malgré les fortes demandes de la communauté pour la conserver.
    Techniquement, c’était probablement la bonne décision, mais socialement elle était très impopulaire et, à mon avis, probablement mauvaise.
  • Content de le voir revenir. Elm a toujours eu une élégance remarquable qui donne envie de l’encourager.
  • Ces deux dernières années, j’ai utilisé Elm professionnellement dans une entreprise très rentable et sans fioritures.
    Je ne le connaissais pas avant d’y entrer, mais comme j’avais de l’expérience avec React, Redux, etc., je l’ai appris rapidement.
    La communauté Elm appellerait sans doute cela une fonctionnalité. Combien de code React écrit il y a 6 à 8 ans fonctionne encore aujourd’hui exactement aussi bien avec la toolchain React actuelle ?
    Les valeurs sont complètement différentes. Du bon code React en 2026 ressemble à du code Elm qui compile depuis 2016.
  • Moi aussi, je pensais que la communauté autour d’Elm avait pratiquement disparu. Cela dit, il semble que le mainteneur unique et créateur soit toujours là.
    Je n’ai jamais utilisé Elm au-delà des tutoriels, mais récemment j’ai créé une application full-stack en Gleam, en m’appuyant surtout sur des agents de codage. Au début, j’ai contrôlé assez strictement la structure du code, et cette façon de faire a plutôt bien fonctionné.

• Ce qui m’intéresse plus qu’Elm 1.0, c’est ce qui vient après Elm 0.19. La 0.19 est la version qui a bloqué tous les modules natifs non officiellement approuvés par l’auteur d’Elm, et à mes yeux cela a marqué, de fait, la fin d’Elm.

• Difficile d’imaginer une annonce pire pour le passage à la 1.0. Qui s’en soucie ? Sans localisation ni prise en charge de l’accessibilité, ça n’a aucun sens d’appeler un framework UI « prêt pour la production » en version 1.0.
  Le fait de limiter la capacité des contributeurs tiers à brancher des API de navigateur a, selon moi, tué l’élan d’Elm en dehors des projets jouets.
  Aujourd’hui, cela ressemble davantage à un bac à sable où Evan joue avec des idées de compilateur qu’à quelque chose destiné à la production.

  • Je ne pense pas que ce soit exact. L’application Elm que je maintiens est entièrement localisée, et je trouve que son accessibilité est plutôt correcte.
    Pour la localisation, nous utilisons un gros record par langue, que nous transmettons à chaque partie de l’application qui utilise des chaînes. Pour les pluriels ou les cas particuliers propres à une langue, on peut mettre de simples fonctions dans le record, ce qui est très pratique.
    Pour l’accessibilité, nous combinons du bon HTML, des ports, et, pour les cas complexes comme un typeahead avec autocomplétion, des composants web.
  • Qu’on les laisse simplement construire. Les gens qui savent vraiment reconnaîtreont quand ce sera prêt, et ceux qui suivent les modes sont de toute façon irrécupérables.
  • D’un côté, ça fait plaisir de voir qu’Evan va bien. Il a de très bonnes idées sur le développement de langages, et Elm a inspiré beaucoup de projets très intéressants.
    De l’autre, après 7 ans sans rien, sortir une petite amélioration des performances du compilateur et appeler ça « la route vers la 1.0 », c’est un peu étrange. Sans mauvaise intention, mais pourquoi ? Le projet était déjà mort, le deuil était fait, et tout le monde est parti depuis longtemps.
    Je pense que beaucoup de gens ne s’en soucieront pas tant qu’il n’y aura pas une version vraiment étonnante.

• Evan pointe quelque chose du doigt, mais tout le monde semble regarder le doigt. À mon avis, il ne s’agit pas vraiment d’Elm lui-même, mais de la préparation d’Acadia.
  Dans sa présentation Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8, il donne un aperçu de ce sur quoi il a travaillé ces 7 dernières années. C’est un langage de requête qui applique des idées fonctionnelles.
  Il identifie les frontières où l’information de type se casse généralement dans les applications web : entre le langage et le stockage, puis entre le stockage et le transport.
  Que gagnerait-on si l’on pouvait préserver l’information de type au-delà de ces frontières ? L’une des réponses qu’il donne est la simplification des migrations. Au lieu d’écrire du SQL à la main, on pourrait les traiter via des différences de types.
  La bonne question, selon moi, est donc de savoir si l’on peut déduire à quoi ressemblera Acadia à partir des changements apportés à Elm. Qu’apporte la compilation incrémentale à un langage de requête ?

  • Vu l’histoire d’Elm, pourquoi devrait-on croire qu’Arcadia ne finira pas de la même manière ?
    Aussi bonnes que soient les idées, si Arcadia n’a pas un modèle de développement plus tourné vers l’avenir et centré sur la communauté, personne ne l’adoptera. Au mieux, ce sera un « projet qui a inspiré XYZ ».
    Evan peut penser que c’est le prochain grand truc, et il a peut-être raison, mais je ne sais pas si le monde d’après Elm l’écoutera suffisamment.

• Ont-ils annulé le fait que certaines fonctionnalités du langage ne pouvaient être utilisées que par l’équipe Elm ? Cela ressemblait à une décision capable de tuer le langage.

• Est-il juste de dire qu’Elm a beaucoup perdu de son élan ? Même sur HN, on n’en discute presque plus, et je me demande si c’est l’une des raisons pour lesquelles les versions et les nouvelles sont si espacées.
  Si l’on regarde l’intervalle entre les versions, la 0.19.2 « Faster builds, and the Road to Elm 1.0 » date de juillet 2026, et la 0.19.1 « Friendly syntax hints, faster builds » d’octobre 2019.

[GN⁺]

Avis sur Lobste.rs

• Waouh ! Elm 0.19.1 est sorti le 21 octobre 2019, donc il y a déjà 7 ans, et c’était aussi la dernière nouvelle publique concernant le développement d’Elm.
  Ça fait vraiment plaisir de voir du nouveau sur le projet.

  • Je suis vraiment impatient de voir Evan préparer une version v1.
  • Je venais justement dire ça.
    J’ai pris beaucoup de plaisir à utiliser Elm sur un projet perso, mais vu de l’extérieur, la communauté semblait un peu calme. C’est une nouvelle très enthousiasmante.

• Elm m’a redonné le goût du développement web.
  J’ai hâte de voir ce que la 1.0 apportera.

• C’est une très agréable surprise.
  J’ai toujours aimé la stabilité d’Elm, et la 1.0 ne semble pas s’orienter vers des changements radicaux, ce qui me paraît être une bonne direction.

  • Le changement cassant décrit pourrait avoir un impact assez important.
    Si == et consorts n’acceptent plus n’importe quel type, il faudra modifier pas mal de code Elm. Je me demande à quoi ressemblera la procédure de mise à niveau.

• Content de voir une mise à jour d’Elm.
  C’est un peu inhabituel qu’un langage de programmation ne reçoive aucune mise à jour pendant plusieurs années. Je comprends les raisons, mais la perception publique a quelque chose d’étrange.

  • Oui, surtout dans le frontend, où tout avance à une vitesse folle.

• J’aime bien cette nouvelle.
  De temps en temps, je retourne jeter un œil à Elm, comme une pause bienvenue loin de la folie du développement frontend moderne.

• J’ai eu l’occasion de voir la présentation d’Evan à ZuriHac 2026, et j’ai été vraiment surpris quand il a laissé entendre qu’une nouvelle version d’Elm arrivait.
  J’espère que la vidéo sera bientôt mise en ligne, mais il semblait avoir compris que viser la stabilité ne cadre pas très bien avec l’obsession de cette industrie pour les progrès rapides. Si j’ai bien compris, Elm pourrait avancer par étapes plus petites et plus rapides. C’est enthousiasmant, et cette présentation m’a beaucoup fait regretter Elm.

• Je me demande comment Elm va gérer des fonctionnalités plus visibles comme les types equatable et hashable.
  L’un des choix de conception controversés du langage est d’éviter les fonctionnalités de système de types plus puissantes à la Haskell, comme les typeclasses. Personnellement, j’ai toujours trouvé gênant de ne pas pouvoir utiliser comme clés de dictionnaire même des types personnalisés ayant un ordre naturel et bien défini. Cela dit, c’est globalement une bonne nouvelle que le travail sur Elm continue.

  • Mieux vaut sans doute ne pas trop espérer de fonctionnalités façon typeclasses.
    À en juger par la formulation du billet de blog, j’imagine qu’il s’agira plutôt d’ajouter quelques nouveaux variables de type contraintes aux variables de type contraintes existantes, à savoir number, appendable, comparable et compappend.