Nouvelle cible de compilation
Depuis la version v1.19.0 (5 octobre 2026), Gleam ne génère plus de code source Erlang. Giacomo Cavalieri a réécrit le générateur pour produire des formes abstraites Erlang, une représentation intermédiaire utilisée par le compilateur Erlang. Cette structure est un arbre annoté de métadonnées, encodé au format externe d’Erlang, ce qui permet de charger directement le résultat dans la machine virtuelle sans passer par l’étape de tokenisation et de parsing du code source.
Impact sur les performances et le débogage
Le passage aux formes abstraites a réduit le temps de compilation de façon notable. Le temps d’exécution du compilateur est plus court, ce qui se traduit par des builds plus rapides, surtout lors de la compilation initiale d’un projet. En outre, les métadonnées de localisation sont maintenant alignées sur le code Gleam d’origine ; les numéros de ligne affichés dans les rapports de plantage BEAM et les traces de pile correspondent exactement aux lignes du fichier Gleam, alors qu’auparavant ils pointaient parfois vers la fonction la plus proche du code Erlang généré. Cette précision ouvre la voie à un support complet des débogueurs comme edb, même si l’équipe n’a pas encore implémenté cette fonctionnalité. Le code du compilateur a également été modernisé, suivant les conventions actuelles du projet, ce qui améliore la maintenabilité globale.
Analyse du benchmark comparatif
Le benchmark, issu du projet langcompilebench de José Valim, compile 100 modules contenant chacun 100 fonctions renvoyant la chaîne « hello world ». La comparaison entre v1.17.0 et v1.19.0 montre une réduction du temps total de compilation, le graphique fourni indiquant clairement que la version 1.19.0 est plus rapide. Lorsque Gleam (cible Erlang) est placé aux côtés de Go, Erlang, Java, Elixir, Elm, Rust, C# et TypeScript, il se situe dans la même fourchette que Go et nettement en dessous d’Elixir et de Java. La version JavaScript de Gleam, quant à elle, reste plus lente que les langages natifs, ce qui reflète la surcharge inhérente à la génération de code JavaScript.
Limites et perspectives
Pourquoi ne pas générer directement du bytecode BEAM ? Bien que cela offrirait potentiellement des gains de performance, le bytecode évolue à chaque version de la VM, imposant une charge de maintenance continue. Reproduire les décennies d’optimisations du compilateur Erlang serait également un effort majeur, même avec l’analyse statique avancée de Gleam. Le projet, financé par des sponsors communautaires, doit donc privilégier des solutions à fort rendement avec un coût de développement limité. En suivant l’exemple d’Elixir, qui compile déjà via les formes abstraites, Gleam a choisi le compromis le plus viable pour aujourd’hui.
