Le langage Goose « plus rapide que Rust » : le benchmark s'égalise dès que la disposition des données est équitable

Le projet Goose est voué à la guerre de religion : une IA a écrit un langage de programmation censé être plus rapide que C++ et Rust. Laissons la querelle aux supporters. Les artefacts qui restent après les polémiques sont bien plus intéressants : ils montrent comment ces comparaisons sont construites et où se cache le piège.

Ce qu'a trouvé MrTeamlead

Dans deux vidéos, le blogueur MrTeamlead analyse le benchmark records_fixed.goose. Selon les auteurs, Goose bat la version Rust de 1,8 fois en mémoire et de 1,9 fois en vitesse. Le blogueur montre que le code Rust peut être accéléré de 6,7 fois si l'on ajoute la parallélisation.

L'analyse de l'auteur de l'article sur Habr montre qu'il y a deux corrections clés :

• Vec::new() a été remplacé par Vec::with_capacity(N). Cette correction est discutable : le benchmark modélise un flux d'événements, dont le nombre n'est pas connu à l'avance.
• String a été remplacé par MyString, qui stocke jusqu'à 15 caractères directement à l'intérieur de l'événement. Cette correction est légitime.

Dans la version Goose, le texte se trouve à l'intérieur de l'enregistrement, tandis que dans la version Rust il est dans le tas via String. Les dispositions de données diffèrent, la comparaison est donc inéquitable. Quand le texte a été placé de la même façon en Rust, le résultat est devenu 46,7 contre 46,5 ms. En somme, le blogueur a écrit le records_fixed.rs manquant.

Goose possède un autre benchmark, records_var.goose, où la longueur du mot (4 à 15 lettres) est un paramètre de génération des données, et non une taille connue du code. Pour celui-ci, records.rs reste une paire correcte. L'auteur de Goose a répondu aux critiques que records_fixed n'était qu'une illustration et que le vrai benchmark est records_var. Il a retiré le fichier contesté du dépôt.

Comment Goose gère la mémoire

L'idée centrale est celle des data stacks. Ce ne sont pas des piles d'appels : elles ne contiennent pas de cadres de fonctions, uniquement des données. Elles sont libérées comme une pile : à la sortie de la portée, le sommet recule. La mémoire est réservée à l'avance, mais n'est rattachée au processus que paresseusement.

Le compilateur calcule le nombre de data stacks à la compilation selon la chaîne d'appels la plus profonde. Seules comptent les fonctions qui détiennent des tableaux dynamiques, et il faut le nombre maximal de tels tableaux vivants simultanément. À l'exécution, aucune nouvelle pile n'apparaît, et une fonction terminée cède sa pile aux appels suivants. Le prix de cette approche : des restrictions pour la récursion. Au moment d'un appel récursif, la fonction ne doit avoir aucun tableau dynamique vivant. Tout ce qui doit survivre à l'appel est créé à l'extérieur et passé par référence.

L'exemple d'une commande à deux lignes (id, nom du client, liste d'articles) rend la différence immédiatement visible :

• Goose : 29 octets par commande et zéro allocation dans le tas.
• Rust : 233 octets avec collect et 153 après shrink_to_fit(), plus quatre allocations dans le tas.

On peut faire la même chose en C, puisque Goose est un transpileur. Mais à la main, c'est fragile : on peut regarder, modifier est dangereux.

Ce que cela signifie en pratique

La première conclusion concerne l'honnêteté des mesures. Avant de comparer « le langage A est plus rapide que le langage B », vérifiez que les données ont la même disposition. Souvent, ce n'est pas le langage qui gagne, mais le placement des données en mémoire. La seconde conclusion concerne le vibe coding. Si une IA écrit le code et qu'il reste peu de temps pour la revue, un langage à mémoire prévisible, sans tas ni allocateurs, réduit le risque d'obtenir par défaut une solution lente. Pour de tels scénarios, Goose paraît plus convaincant que Rust, où un code « naïf » se révèle facilement inefficace.

Les limites comptent aussi. Goose gagne là où il y a beaucoup d'allocations mémoire et où les calculs s'exécutent dans un seul thread. Pour égaler Rust en calcul pur, il lui faut des boucles parallèles (par for) et la vectorisation (simd for), qui restent à implémenter. Pour l'échelle : le dépôt a moins de trois mois (août 2026), alors que Rust a mis cinq ans et demi à arriver à rayon. Les problèmes fondamentaux du langage, eux, n'ont pas disparu.

La leçon principale dépasse un seul projet. Orca, dont l'auteur parle à la fin de l'article, a démarré en mars 2026 et totalise près de 17 000 commits et plus de six millions de lignes de code, tests compris. Auparavant, un tel langage serait resté un projet personnel pendant des années. Aujourd'hui, la vitesse de création d'outils avec l'IA est telle que les « cygnes noirs » (ici « oies noires ») sont devenus réalité. Quant aux benchmarks, il faut les revérifier immédiatement.