Goose : un langage système memory-safe sans GC ni annotations de durée de vie
Sommaire
En bref
- Goose est un langage de programmation système qui supprime le tas au profit de piles de données gérées par le compilateur, chacune se libérant à la fin de sa portée.
- Le langage affiche des performances supérieures à C++ et Rust sécurisé sur les benchmarks fournis (3,3x plus rapide que C++ idiomatique, 1,9x moins de mémoire), sans annotations de durée de vie ni gestionnaire de mémoire.
- L'approche repose sur une analyse de compilateur statique pour inférer les racines des références et garantir la sécurité, compatible avec C via génération d'un fichier C unique.
Ce que dit la source
L'auteur pose que la gestion de la mémoire dynamique (allocation, garbage collection, décompte de références) est le principal frein aux performances et à la simplicité des langages modernes. Goose élimine ces mécanismes en confiant au compilateur l'attribution statique de piles de données, chacune se vidant automatiquement à la sortie de portée, sans que le programmeur n'ait à annoter les durées de vie.
- Le compilateur infère statiquement le nombre et la taille des piles de données, libérant une structure complète en une seule opération mémoire (un store sur le pointeur de pile), même si elle contient un million d'éléments imbriqués.
- Les références restent valides lors de la croissance d'un tableau, car le modèle de mémoire ne réalloue jamais : contrairement à C++ qui doit appeler reserve() ou Rust qui utilise des indices u32, Goose conserve des références typées et vérifiées.
- Pas de syntaxe de durée de vie, pas de règles d'alias ou d'exclusivité, le compilateur inférant les racines des références et rejetant celles qui pourraient survivre à leurs propriétaires.
- Les énums à variantes de tailles différentes consomment la taille de leur variante actuelle, non celle du plus grand variant (4x moins de mémoire et 2x plus rapide que Rust sur le benchmark correspondant).
- Les références relatives codent un lien typé vérifié sur 1, 2 ou 4 octets au lieu d'un pointeur plein, créant des structures position-indépendantes qu'on peut écrire et charger en bloc en fichier.
- Les threads n'ont pas de mémoire partagée : chaque worker est compilé comme un programme distinct, les valeurs plates circulant entre threads via des files typées avec un memcpy.
- Le langage compile en C et peut appeler C directement via extern fn, avec un backend TinyCC embarqué qui compile et exécute le programme en processus sans étape de compilation externe.
Dans les commentaires
Débat divisé entre fascination technique et doutes pratiques. Plusieurs commentateurs soulèvent des questions légitimes sur les limites du modèle (représentation de structures dynamiques complexes, croissance de piles en temps de vie long), tandis que d'autres valorisent l'approche de conception du langage et reconnaissent son apport pédagogique ou comme source d'inspiration pour l'optimisation.
- Un contributeur conteste la comparaison C++ en soulignant que l'exemple du tutoriel utilise des chaînes éligibles à small string optimization, un mécanisme que les implémentations STL modernes appliquent déjà, ce qui affaiblit la démonstration d'avantage sur la gestion mémoire de base.
- Plusieurs commentateurs posent la question d'architecture : comment représenter un nombre arbitraire de valeurs dynamiquement dimensionnées si le langage expose un nombre fixe de piles ? Un exemple concret, les tables de hachage avec des valeurs chaînes, semble délicat sans compaction périodique ou hand-rolled malloc.
- Des commentateurs rappellent que les langages de recherche ML ont exploré des approches par régions dans le passé et ont rencontré des programmes avec une empreinte mémoire trop importante, abandonnant le concept, sans clarifier si Goose évite ces pièges ou s'il cible un sous-ensemble de programmes différent.
- Le modèle sans allocation dynamique est perçu comme naturel et validé pour les systèmes embarqués, les jeux avec reuse mémoire, et les applications data-oriented, mais le fil ne converge pas sur les classes de problèmes bien servies ou mal servies.
Notre lecture
Goose est une exploration sérieuse et documentée d'une alternative aux modèles de gestion mémoire conventionnels, avec des résultats de benchmark prometteurs et une syntaxe lisible. Son intérêt pour une DSI dépend du profil de charge : applications data-oriented, systèmes embarqués ou jeux aux patterns mémoire stables pourraient en tirer parti. Les débats non résolus autour de la scalabilité en structures complexes et la comparabilité réelle avec C++ (notamment sur small string optimization) demandent une évaluation empirique sur un vrai code métier avant d'investir. L'absence d'adoption productive à date et le statut de langage jeune militent pour une veille attentive plutôt qu'une décision d'adoption immédiate, sauf pour des équipes ayant des défis très spécifiques de performance mémoire et une tolérance au risque élevée.