Elm 0.19.2 verbessert die Build-Geschwindigkeit

• Elm 0.19.2 ist der erste Schritt in einer Reihe mehrerer kleiner Releases, mit denen Compiler-Verbesserungen vor Elm 1.0 einfließen sollen
• In großen Elm-Codebasen wurde eine Kompilierung von Grund auf mit 5,7 Sekunden gemessen, nachfolgende inkrementelle Builds mit unter 350 ms; dadurch sinkt die Wahrscheinlichkeit, dass der Fokus im Entwicklungsfluss unterbrochen wird
• Die Verbesserungen konzentrierten sich darauf, während des Parsings weniger Allokationen zu erzeugen; in einem Experiment mit 850.000 Zeilen wurden 20 % weniger GC-Kopieraufwand, 10 % weniger maximaler Speicherverbrauch und 7 % höhere Gesamtgeschwindigkeit beobachtet
• In Tests mit realen Projekten fiel der Zugewinn unterschiedlich aus; ein Fall mit 351 Modulen, die von Grund auf kompiliert wurden, sank von 4,981 Sekunden auf 2,595 Sekunden und wurde damit 1,9-mal schneller
• Performance- und Sprachideen aus der Arbeit an Acadia sollen künftig schrittweise in Releases ohne Kompatibilitätsbruch einfließen; nach dem letzten Feinschliff soll Elm 1.0 folgen

---

Schnellere Kompilierung in Elm 0.19.2

• Elm 0.19.2 ist das erste Release, das angesammelte Compiler-Verbesserungen in kleinen Schritten in Elm einbringt
• Ein schneller Compiler reduziert Situationen, in denen Entwickler in einen Browser-Tab wechseln und dabei den Fokus verlieren
  • Wenn inkrementelles Kompilieren unter 400 ms bleibt, gibt es kaum eine Lücke, um zu einer anderen Aufgabe zu wechseln
• Die Performance auf Basis von 850.000 Zeilen Elm sieht wie folgt aus
  • Kompilierung von Grund auf: 5,7 Sekunden
  • Inkrementeller Build: unter 350 ms
• Die eigentlichen Änderungen konzentrierten sich darauf, während des Parsings Allokationen zu reduzieren
  • 20 % weniger GC-Kopieraufwand
  • 10 % weniger maximaler Speicherverbrauch
  • 7 % höhere Gesamtgeschwindigkeit
• Bei Programmen mit mehr als 500.000 Zeilen sind moderate Verbesserungen zu erwarten; bei kleineren Programmen bleibt der Elm-Compiler weiterhin sehr schnell
• In Tests unter realen Bedingungen variierte der Verbesserungsgrad je nach Projekt
  • Einige Projekte verbesserten sich leicht
  • Beim Kompilieren von 351 Modulen von Grund auf sank die Zeit von 4,981 Sekunden auf 2,595 Sekunden, eine 1,9-fache Verbesserung
• Die neue Version ist im Release des Elm-Compilers 0.19.2 verfügbar

Die nächsten Releases auf dem Weg zu Elm 1.0

• Ideen aus der compilerbezogenen Datenbank-Arbeit namens Acadia sollen auch in Elm genutzt werden
  • Acadia befindet sich derzeit in einer geschlossenen Alpha
  • Die öffentliche Vorstellung ist für Ende dieses Jahres geplant
• Die Ideen, die in Elm einfließen sollen, umfassen sowohl Performance-Verbesserungen als auch Sprachfunktionen
  • Beispiel: ein schnellerer Parser
  • Beispiel: equatable- und hashable-Typen
• Diese Änderungen sollen als Serie kleiner Releases ohne Kompatibilitätsbruch einfließen, damit sie natürlich in Elm integriert werden
• In der letzten Feinschliff-Phase ist der Übergang zu Elm 1.0 geplant
• Wer Elm neu kennenlernt, kann mit den Online-Beispielen und dem Guide starten
• Elm 0.19.2 ist ein Patch-Release und kann daher auch in bestehenden Projekten einfach heruntergeladen und direkt genutzt werden

[GN⁺]

Hacker-News-Kommentare

• Heutzutage sehe ich Elm eher als eine einflussreiche Forschungssprache
  Der Fokus ist klar, aber es gibt weder eine öffentliche Roadmap noch offiziellen Support, und die Führung scheint kaum Interesse daran zu haben, eine Community oder ein Core-Team aufzubauen
  Trotzdem arbeitet es sich wirklich hervorragend damit, und daraus sind mehrere Forks und abgeleitete Projekte entstanden. Auf der letzten Gleam-Konferenz scherzte Louis Pilfold, dass „jeder Elm-Nutzer seinen eigenen Compiler pflegt“, und tatsächlich gibt es mindestens sechs, dazu wurden allein im letzten Monat noch zwei weitere angekündigt
  Es freut mich, dass Evan sich auf 1.0 zubewegt, und ich hoffe, dass er Elm dann als „fertig“ bezeichnet und eines der Nachfolgeprojekte die schwierige Aufgabe übernimmt, Forks zusammenzuführen und die Community wachsen zu lassen
  Wenn ich persönlich als Nächstes etwas Elm-Ähnliches suchen würde, würde ich mir Gleam + Lustre anschauen. Die Kombination aus Maintainern, die sich um Community und Design kümmern, wirkt vielversprechend, und es läuft sowohl im Frontend als auch im Backend

  • Die Entwicklung von Elm war ziemlich seltsam, aber es ist wohl treffend, es eine Forschungssprache zu nennen
    Eine Zeit lang wurde es mit großer Begeisterung verbreitet, es gab viele Blogposts und Vorträge, und das Interesse wie auch die Einführung waren beträchtlich
    Dann ist der Autor praktisch verschwunden und das Projekt kam zum Stillstand
    Natürlich ist es sein Projekt und er hat das Recht dazu, aber ich finde, die Erwartungen hätten von Anfang an besser gesetzt werden müssen. Die aktive Verbreitung hat zwar geholfen, Ideen zu verbreiten, aber auch dazu geführt, dass Entwickler sich plötzlich im Stich gelassen fühlten
  • Das Beste an Elm ist, dass es sich stark nach Haskell anfühlt. Ich habe vor ein paar Jahren einige interessante Dinge mit Elm gebaut
    Das Zweitbeste ist die Philosophie „wenn es kompiliert, funktioniert es“. Ehrlich gesagt bekomme ich bei weiten Teilen von Rust ein ähnliches Gefühl. Weniger Haskell-Gefühl, aber immerhin so etwas wie den warmen Schatten funktionaler Vorfahren
  • Gren wirkte wie ein ausreichend kompetenter Nachfolger, und die Community ist aktiv und hilfsbereit
  • Ich bin auch einer davon. Ich habe die Sprache erweitert und mehrere Komfortfunktionen eingebaut, im Wesentlichen mit Unterstützung für richtige Error Channels und Dependency Injection über löschbare Sum Types
    Elm ist eine gute Sprache, aber Evan scheint kein Interesse daran zu haben, etwas wirklich Nützliches zu bauen, und der gesamte Betrieb der Sprache ist chaotisch
  • Ich glaube, die Leute sind von der Stagnation enttäuscht, gerade weil Elm so gut ist. Aber genau diese Stagnation ist auch der Grund, warum Elm gut ist

• Ich habe 2023 einen Artikel darüber geschrieben, warum ich Elm immer noch benutze
  https://taylor.town/elm-2023
  Und jetzt, im Jahr 2026, benutze ich Elm aus denselben Gründen immer noch :)
  Nebenbei scheint Claude auch sehr gut zu Elm zu passen
  https://taylor.town/diggit-000

• Vor etwa zwei Jahren habe ich als Experiment mit ChatGPT-Vibecoding versucht, ein Snake-Spiel für den Browser in meiner Lieblingssprache Elm zu bauen
  Damals war das noch ziemlich roh, und ich kam zu dem Schluss, dass große Sprachmodelle Elm töten könnten
  Inzwischen nutze ich Elm in Produktion, und große Sprachmodelle sind deutlich besser geworden. Eher glaube ich inzwischen, dass Elm heute eine ideale Sprache für große Sprachmodelle ist und ihre Verbreitung sogar steigern könnte. Es ist einfacher als die meisten Sprachen, stabil und bringt eine stark meinungsgeprägte Architektur direkt in der Sprache mit, weshalb sich Codebasen sehr stark ähneln

  • Dank KI beschäftige ich mich auch mehr mit Musik, habe mir ein MIDI-Keyboard gekauft und sogar richtige DAW-Software eingerichtet
    Ich baue auch mehr mit Rust und lese mehr Rust-Dokumentation. Große Sprachmodelle sollten keine Ausrede dafür sein, das eigentliche Zielgebiet nicht zu lernen; wer so vorgeht, ist ein schlechter Ingenieur
    Große Sprachmodelle verschaffen einem Zeit zum Recherchieren und Lernen, damit man die erzeugten Ergebnisse auch warten kann. Wenn man das Problem versteht, kann man auch bessere Prompts schreiben
  • Die Aussage, dass große Sprachmodelle die Einführung von Elm fördern könnten, ist zugleich richtig und falsch
    Am Ende hängt es davon ab, wie stark Elm in den Trainingsdaten und im RLHF vertreten ist. Ich stimme zu, dass strukturierte Frameworks oder Sprachen die Generierung erleichtern, weil sich Codebasen stärker ähneln
    Aber das allein reicht nicht aus, und die Einführung durch Entwickler ist in der Regel als Thema deutlich komplexer
  • Vielleicht hat es sich verbessert, aber ich war ziemlich enttäuscht davon, wie Agenten wie Claude Code immer wieder über die bedeutungsvollen Leerstellen in Elm gestolpert sind
    Mit Python geht es ausgezeichnet um, was seltsam wirkte, denn Elm ist eine der stabilsten Sprachen der modernen Ära. So stabil, dass Leute sich sogar darüber beschweren, dass es sich nicht verändert. Mein letzter Versuch ist allerdings etwa ein Jahr her, also ist es inzwischen vermutlich besser geworden
  • Diese Sichtweise ist nachvollziehbar. So hatte ich noch nicht darüber nachgedacht, aber wenn sich das Ökosystem nicht weiterbewegt, würde ich trotzdem zögern

• Wurden die Einschränkungen rund um JavaScript gelöst? Soweit ich mich erinnere, musste man für die Anbindung an JavaScript den Ports-Mechanismus von Elm verwenden, und direkte Wrapper waren wohl nicht erlaubt
  Ich meine, es gab auch Kontroversen, als jemand einen Fork machte, um direkte JavaScript-Wrapper oder FFI zu ermöglichen

  • FFI wird weiterhin größtenteils über ports abgewickelt. Auf der View-Seite nutzt man manchmal Web Components
    Das ist eine bewusste Entscheidung und wird voraussichtlich bis 1.0 und wahrscheinlich auch danach so bleiben

• Ich wusste nicht, dass dieses Projekt noch lebt. Nicht als Spott gemeint, aber ich dachte, es sei längst vorbei

  • Das Projekt war tot. Das vorherige Release liegt 7 Jahre zurück, und nachdem der Gründer die Wartung eingestellt hatte, kam die Community nicht über das BDFL-Modell hinaus und alles blieb einfach stehen
    Es war also tot und ist jetzt gerade erst so etwas wie wiederbelebt worden. In der Zwischenzeit dürfte die Community stark geschrumpft sein
  • Ich war nicht tief in die Community eingebunden, aber ich kenne Leute, die damals beteiligt waren, und soweit ich es verstanden habe, hat vor allem die Entfernung benutzerdefinierter Infix-Operatoren viel Unterstützung in der Community gekostet
    Das war eine sehr beliebte Funktion, wurde aber entfernt, weil der Sprachgründer sie nicht mochte, obwohl die Community stark dafür plädiert hatte, sie zu behalten
    Technisch war das vermutlich die richtige Entscheidung, gesellschaftlich war sie aber sehr unpopulär und vermutlich falsch
  • Schön, dass es zurück ist. Elm hatte immer eine erstaunliche Eleganz, der man einfach die Daumen drücken will
  • Ich habe Elm in den letzten 2 Jahren beruflich in einem sehr profitablen, schnörkellosen Unternehmen eingesetzt
    Vor meinem Einstieg kannte ich es nicht, aber ich hatte Erfahrung mit React, Redux usw. und habe es deshalb schnell gelernt
    Die Elm-Community würde das wohl als Feature bezeichnen. Wie viel React-Code von vor 6–8 Jahren läuft heute noch völlig unverändert in der modernen React-Toolchain?
    Die Wertehaltung ist völlig anders. Guter React-Code im Jahr 2026 sieht ähnlich aus wie Elm-Code, der seit 2016 kompiliert
  • Ich dachte auch, dass die Community rund um Elm praktisch verschwunden sei. Trotzdem scheint der alleinige Maintainer und Gründer noch da zu sein
    Außer Tutorials habe ich Elm nie benutzt, aber vor Kurzem habe ich eine Gleam-Full-Stack-App gebaut und dabei größtenteils Coding-Agents verwendet. Am Anfang habe ich die Codestruktur ziemlich strikt kontrolliert, und das hat überraschend gut funktioniert

• Mich interessiert Elm nach 0.19 mehr als Elm 1.0. 0.19 war die Version, die alle nicht offiziell vom Elm-Autor genehmigten nativen Module blockiert hat, und für mich markierte das faktisch das Ende von Elm

• Es ist schwer, sich eine schlechtere Ankündigung auf dem Weg zu 1.0 vorzustellen. Wen interessiert das? Wenn es keine Lokalisierung oder Accessibility-Unterstützung gibt, ist es Unsinn, ein UI-Framework als produktionsreifes 1.0 zu bezeichnen
  Dass der Spielraum für Drittanbieter-Beitragende eingeschränkt wurde, Browser-APIs anzubinden, hat der Dynamik von Elm außerhalb von Spielzeugprojekten meiner Meinung nach den Todesstoß versetzt
  Im Moment wirkt es eher wie eine Sandbox, in der Evan mit Compiler-Ideen spielt, als etwas für den Produktionseinsatz

  • Ich finde, das stimmt so nicht. Die Elm-App, die ich warte, ist vollständig lokalisiert, und ich halte auch die Accessibility für ziemlich gut
    Lokalisierung lösen wir über einen großen Record pro Sprache, der an jeden Teil der App weitergereicht wird, der Strings verwendet. Für Pluralformen oder sprachspezifische Sonderfälle kann man einfach Funktionen im Record hinterlegen, was sehr praktisch ist
    Accessibility erreichen wir durch gutes HTML, ports und bei komplexeren Fällen wie Autocomplete-Typeahead durch die Kombination mit Web Components
  • Man sollte sie einfach machen lassen. Die Leute, die wirklich Bescheid wissen, werden es erkennen, wenn es so weit ist, und Trend-Mitläufer sind ohnehin nicht zu retten
  • Einerseits ist es schön zu sehen, dass es Evan gut geht. Er hat ziemlich gute Ideen zur Sprachentwicklung, und Elm hat viele sehr interessante Projekte inspiriert
    Andererseits ist es schon etwas seltsam, nach 7 Jahren ohne irgendetwas eine kleine Compiler-Performance-Verbesserung zu veröffentlichen und das dann „Road to 1.0“ zu nennen. Nicht böse gemeint, aber warum überhaupt? Es war bereits tot, die Trauerphase ist vorbei, und die Leute sind längst weitergezogen
    Ich glaube nicht, dass es viele interessieren wird, bevor nicht ein wirklich erstaunliches Release kommt

• Evan zeigt auf etwas, aber alle scheinen nur auf den Finger zu schauen. Ich denke, es geht hier in Wahrheit nicht um Elm selbst, sondern um die Vorbereitung von Acadia
  In seinem Vortrag Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8 gibt er einen kleinen Einblick in das, woran er in den letzten 7 Jahren gearbeitet hat. Es ist eine Abfragesprache mit angewandten funktionalen Ideen
  Er zeigt auf die Grenzen in Web-Apps, an denen Typinformationen normalerweise verloren gehen: zwischen Sprache und Datenbank sowie zwischen Datenbank und Transport
  Was würde man gewinnen, wenn man Typinformationen über diese Grenzen hinweg erhalten könnte? Eine seiner Antworten ist einfachere Migration. Statt SQL von Hand zu schreiben, könnte man Typ-Diffs dafür nutzen
  Daher ist die richtige Frage meiner Meinung nach, ob man aus den Änderungen in Elm ableiten kann, wie Acadia aussehen wird. Was würde inkrementelle Kompilierung einer Abfragesprache bringen?

  • Wenn man die Geschichte von Elm betrachtet, warum sollte man glauben, dass es bei Arcadia anders laufen wird?
    Selbst wenn die Ideen noch so gut sind: Wenn Arcadia kein zukunftsfähigeres und communityzentriertes Entwicklungsmodell hat, wird es niemand übernehmen. Im besten Fall wird es nur ein „Projekt, das XYZ inspiriert hat“
    Evan mag glauben, dass das das nächste große Ding ist, und vielleicht hat er sogar recht, aber ich weiß nicht, ob die Welt nach Elm noch genug zuhört

• Wurde das zurückgenommen, dass nur das Elm-Team bestimmte Sprachfeatures nutzen durfte? Das wirkte wie eine Entscheidung, die eine Sprache töten kann

• Ist die Einschätzung richtig, dass Elm viel Momentum verloren hat? Selbst auf HN wird es kaum noch diskutiert, und ich frage mich, ob das einer der Gründe für die großen Abstände zwischen Releases und Neuigkeiten ist
  Wenn man die Release-Abstände betrachtet, ist 0.19.2 „Faster builds, and the Road to Elm 1.0“ von Juli 2026, und 0.19.1 „Friendly syntax hints, faster builds“ von Oktober 2019

[GN⁺]

Meinungen auf Lobste.rs

• Wow! Elm 0.19.1 erschien am 21. Oktober 2019, also schon vor 7 Jahren, und das war auch die letzte öffentliche Nachricht zur Elm-Entwicklung.
  Es ist ziemlich schön, Neues von dem Projekt zu sehen.

  • Dass Evan ein v1-Release plant, macht mich wirklich gespannt.
  • Genau das wollte ich auch sagen.
    Als ich Elm für ein Nebenprojekt ausprobiert habe, hat es wirklich Spaß gemacht, aber von außen wirkte die Community etwas still. Sehr spannende Nachricht.

• Elm hat Webentwicklung wieder spaßig gemacht.
  Ich bin gespannt, was 1.0 bringen wird.

• Eine wirklich erfreuliche Überraschung.
  Ich mochte die Stabilität von Elm schon immer, und es sieht so aus, als würde 1.0 keine radikalen Änderungen bringen, was ich persönlich für die richtige Richtung halte.

  • Die beschriebenen Breaking Changes könnten ziemlich große Auswirkungen haben.
    Wenn == und Ähnliches nicht mehr beliebige Typen akzeptieren, wird es einiges an Elm-Code geben, der angepasst werden muss. Ich bin gespannt, wie der Upgrade-Prozess aussehen wird.

• Schön, ein Elm-Update zu sehen.
  Dass eine Programmiersprache über Jahre hinweg keinerlei Updates bekommt, ist etwas ungewöhnlich. Ich verstehe die Gründe, aber öffentliche Wahrnehmung ist eben eine merkwürdige Sache.

  • Stimmt, besonders im Frontend, wo sich alles in wahnsinnigem Tempo bewegt.

• Gute Nachricht.
  Ab und zu schaue ich mir Elm wieder an, wie eine wohltuende Pause vom Wahnsinn moderner Frontend-Entwicklung.

• Ich hatte die Gelegenheit, Evans Vortrag auf der ZuriHac 2026 zu sehen, und war wirklich überrascht, als er andeutete, dass ein neues Elm-Release kommt.
  Ich hoffe, das Video erscheint bald, aber er schien verstanden zu haben, dass der auf Stabilität ausgerichtete Ansatz nicht gut zur Fixierung der Branche auf schnellen Fortschritt passt. So wie ich es verstanden habe, könnte Elm kleinere und schnellere Schritte gehen. Ich bin gespannt, und der Vortrag hat mir Elm wieder sehr in Erinnerung gerufen.

• Ich bin neugierig, wie Elm auffälligere Features wie equatable- und hashable-Typen angehen wird.
  Eine der umstrittenen Designentscheidungen dieser Sprache ist, stärkere Haskell-artige Typsystem-Features wie Typklassen zu vermeiden. Persönlich fand ich es immer störend, dass man selbst Custom Types mit einer natürlichen und wohldefinierten Ordnung nicht als Dictionary-Schlüssel verwenden kann. Trotzdem ist es insgesamt eine gute Nachricht, dass die Arbeit an Elm weitergeht.

  • Man sollte wohl nicht zu sehr auf typklassenartige Features hoffen.
    Nach der Formulierung im Blogpost stelle ich mir vor, dass es eher darum geht, zusätzlich zu den bestehenden eingeschränkten Typvariablen, also number, appendable, comparable und compappend, ein paar neue eingeschränkte Typvariablen hinzuzufügen.