Gleam, die typensichere Sprache, die für die Erlang-Virtual-Machine und JavaScript-Runtimes entwickelt wurde, schreibt ihren Erlang-Output nicht mehr als einfachen Quellcode aus. Stattdessen generiert sie jetzt Erlang-Abstrakte-Formen – eine interne Darstellung, die der Erlang-Compiler direkt liest, wobei der Schritt des Ausgeben von menschenlesbarem Code übersprungen wird. Die Änderung landete in Gleam v1.19.0, und Entwickler Giacomo Cavalieri leistete die Arbeit in den letzten Monaten.
Der Wechsel ist ein großer Deal für Gleam-Programmierer, die jetzt schnellere Builds, genauere Crash-Reports und einen saubereren Codebase erhalten. Er schließt auch die Tür zu einem Wort, das niemand hören wollte: Transpiler.
Was die Abstraktionsform-Änderung bewirkt
Bisher kompiliert Gleam in Erlang-Quellcode, wie jede andere Sprache, die auf der BEAM abzielt. Jetzt erzeugt sie Erlang-Abstrakte-Formen, eine baumartige Struktur, die mit Metadaten versehen ist, die der Compiler intern verbraucht. Dieses Format hat eine binäre Kodierung unter Verwendung des externen Term-Formats von Erlang, was bedeutet, dass Gleam es direkt in den Erlang-Compiler einspeisen kann, ohne jemals eine Datei zu berühren.
Das Ergebnis ist ein vollständiger Build, der schneller läuft, wie die in der Ankündigung gezeigten Benchmarks zeigen. Der Unterschied ist besonders auffällig bei großen Projekten, bei denen der Compiler echte Zeit damit verbringt, Code zu parsen und zu validieren, der die Abstraktionsform bereits enthält.
Warum die Zeilennummern wichtig sind
Genaue Zeilennummern in Crash-Reports waren vor dieser Änderung ein Problem. Wenn ein BEAM-Prozess abstürzt, meldet die Erlang-Runtime die Zeilennummer der nächsten Funktion im generierten Erlang-Code, nicht den ursprünglichen Gleam-Quellcode. Das bedeutete, dass das Debugging oft das Durchlesen einer generierten Datei beinhaltete, um die tatsächliche Zeile des Codes zu finden, die fehlgeschlagen ist.
Jetzt bleiben die Metadaten an der ursprünglichen Gleam-Quelle befestigt. Ein Crash-Report verweist auf die richtige Zeile in der Gleam-Datei, anstatt auf die nächste Funktion im generierten Code. Dies ist ein Qualitätsverbesserung für alle, die Stunden damit verbracht haben, einen Fehler durch generierten Code zu verfolgen.
Die Ankündigung weist darauf hin, dass diese Metadaten auch eine vollständige Unterstützung von Gleam in Debuggern wie edb ermöglichen könnten, obwohl das Gleam-Team selbst noch keine Arbeit in diese Richtung geleistet hat.
Die Performance-Gewinne
Die Referenzdaten stammen aus José Valims langcompilebench-Projekt, das die Zeit misst, die benötigt wird, um 100 Module mit je 100 Funktionen zu kompilieren, die alle einen „hello world“-String zurückgeben. Der Test ist einfach, aber er ist konsistent über verschiedene Sprachen hinweg, was ihn auch dann noch nützlich für Vergleiche macht, wenn er nicht die reale Komplexität widerspiegelt.
Das Diagramm zeigt eine deutliche Verbesserung zwischen v1.17.0 und der neu veröffentlichten v1.19.0. Der Test ist ein vollständiger Build von Grund auf, ohne Caching, so dass er das Worst-Case-Szenario misst. In der normalen Entwicklung, in der der Compiler nur geänderte Dateien berührt, wäre die Beschleunigung noch deutlicher zu bemerken.
Wie Gleam im Vergleich zu anderen Sprachen abschneidet
Die ursprüngliche langcompilebench umfasste nur Erlang, Elixir und Gleam. Die Ankündigung erweitert den Test auf eine Reihe beliebter Programmiersprachen, darunter Gleam, das in JavaScript kompiliert. Hier ist, wie die Ergebnisse aussehen:
| Sprache | Kompilierzeit |
|---|---|
| Erlang | Basislinie |
| Elixir | Schneller als Erlang |
| Gleam (Erlang) | Schneller als Elixir |
| Gleam (JavaScript) | Slower als Erlang |
Die vollständige Tabelle zeigt, dass Gleam im Vergleich zu den Sprachen, mit denen es konkurriert, gut mithalten kann, und das JavaScript-Ziel bietet Entwicklern, die in beiden Umgebungen arbeiten, einen nützlichen Vergleich. Die Ankündigung weist vorsichtig darauf hin, dass es sich um einen konstruierten Benchmark und nicht um ein definitives Maß für die Leistung in der realen Welt handelt.
Warum nicht Bytecode?
Eine offensichtliche Frage ist, warum Gleam nicht direkt auf BEAM-Bytecode abzielt. Die Antwort ist, dass Bytecode nicht festgelegt ist. Jede neue Version der virtuellen Maschine kann Funktionen hinzufügen oder entfernen, was bedeutet, dass ein Bytecode-Generator mit den laufenden Änderungen Schritt halten müsste.
Die Ankündigung rahment dies als eine Ressourcenbeschränkung. Gleam ist ein Community-Projekt, das durch Sponsoring unterstützt wird, mit einem Bruchteil der finanziellen Mittel, die für unternehmensfinanzierte oder akademisch finanzierte Sprachen zur Verfügung stehen. Das Team argumentiert, dass die Kompilierung in abstrakte Formen die effizienteste Nutzung ihrer begrenzten Ressourcen darstellt.
„Die Kompilierung in Erlang-Abstrakte-Formen ist der kosteneffiziente Sweet-Spot für Gleam heute.“
Elixirs Präzedenzfall
Die Ankündigung weist darauf hin, dass auch Elixir selbst in Erlang über abstrakte Formen kompiliert. Die Argumentation ist einfach: Wenn es für Elixir gut genug ist, ist es für Gleam gut genug.
Diese Präzedenz hat Gewicht, da Elixir in abstrakte Formen kompiliert. Wenn die Erlang-Wartender selbst abstrakte Formen als den Standardpfad betrachten, macht es für eine jüngere Sprache Sinn, denselben Weg zu gehen.
Das Gesamtbild
Das Rewrite ist nicht nur eine Leistungsverbesserung. Es verbessert auch die Qualität des Codes, den der Compiler generiert, so die Ankündigung. Der Erlang-Code-Generator war einer der ältesten und stabilsten Teile des Gleam-Codebasis, und obwohl er keine Probleme verursachte, entsprach er nicht den aktuellen Standards und Konventionen des Teams.
Der neue Generator wird als exzellent beschrieben, und die Ankündigung argumentiert, dass er die Messlatte für den Compiler als Ganzes anhebt.
Was das für Entwickler bedeutet
Für einen Gleam-Programmierer ist die praktische Schlussfolgerung einfach: Builds sind schneller, und das Debugging ist präziser. Die Ausgabe in abstrakter Form bedeutet, dass der Compiler weniger Zeit damit verbringt, Aufgaben zu erledigen, die der BEAM-Compiler bereits erledigt, und die Metadaten bedeuten, dass Crash-Reports auf die korrekte Codezeile verweisen.
Die Ankündigung endet mit einem Witz: Das Team muss nie wieder jemanden dabei zuhören, wie er das Wort „Transpiler“ abwertend verwendet.
Das ist ein kleiner Sieg, aber ein echter. Eine Sprache, die in abstrakte Formen kompiliert, ist kein Transpiler im abwertenden Sinne – sie ist ein Compiler, der die Muttersprache des BEAM direkt spricht.
Quelle: “Gleam kompiliert nicht mehr in Erlang-Quellcode,” gleam.run.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.