Luau – un langage de script basé sur Lua, rapide, léger, sûr et doté d’un typage progressif

 (luau.org)
7 points par GN⁺ 2025-09-23 | 1 commentaires | Partager sur WhatsApp
  • Luau est un langage de script embarqué dérivé de Lua 5.1, rapide, sûr et prenant en charge le typage progressif
  • Il a évolué en renforçant les performances, les outils du langage et le système de types afin de prendre en charge des jeux complexes et de grandes bases de code sur la plateforme Roblox
  • Contrairement à Lua standard, il intègre des fonctions de sandboxing afin de permettre l’exécution côte à côte de codes ayant des niveaux de privilèges différents
  • La syntaxe est compatible avec Lua 5.1, mais il fournit aussi des extensions syntaxiques supplémentaires et des outils d’analyse (linter, vérificateur de types) pour améliorer la qualité du code
  • Grâce à l’optimisation des performances, à un bytecode personnalisé et à la prise en charge du JIT, il vise des vitesses d’exécution au niveau de LuaJIT et présente un fort potentiel d’utilisation au-delà de Roblox, dans divers environnements embarqués

Motivation

  • Vers 2006, Roblox a adopté Lua 5.1 comme langage de script pour les jeux
  • Avec le temps, à mesure que le niveau des jeux sur la plateforme Roblox augmentait et que la taille des équipes grandissait, le langage et son implémentation ont été fortement améliorés pour dépasser les limites de Lua existant
  • Avec la croissance de la plateforme, d’importants investissements ont été réalisés dans l’optimisation des performances, la facilité d’utilisation et le développement d’outils liés au langage
  • En particulier, avec la gestion de grandes bases de code dépassant le million de lignes en 2020, il est devenu évident qu’un système de typage progressif était indispensable
  • Sur cette base, Roblox a développé Luau, un langage dérivé de Lua, offrant un ensemble de fonctionnalités à la fois rapide, léger, sûr et permettant d’appliquer progressivement les types
  • Des explications plus détaillées sont disponibles dans le document Why Luau

Présentation de Luau

  • Luau est un langage de script embarqué basé sur Lua 5.1
    • Il fournit un runtime rapide et léger
    • Il prend en charge un système de typage progressif permettant de combiner analyse dynamique et statique
  • Il est intégré à Roblox Studio, et le mode strict peut être activé avec le flag --!strict
  • Les développeurs peuvent consulter la documentation liée à Roblox dans Luau Creator Docs

Sandboxing

  • Luau limite la bibliothèque standard exposée et fournit des mécanismes de sandboxing supplémentaires
  • Cela permet d’exécuter en parallèle, de manière sûre, du code non privilégié écrit par des développeurs ordinaires et du code privilégié interne à la plateforme
  • Cela lui donne un environnement d’exécution différent de Lua standard
  • Les détails sont disponibles dans la documentation Sandbox

Compatibility

  • Il conserve autant que possible une compatibilité descendante avec Lua 5.1, tout en intégrant partiellement certaines fonctionnalités de versions ultérieures
  • Cependant, Luau n’adopte pas toutes les décisions de conception de Lua et reflète les cas d’usage et contraintes propres à Roblox
  • L’état de prise en charge des fonctionnalités postérieures à Lua 5.1 est présenté dans la documentation Compatibility

Syntax

  • Il est entièrement compatible avec la syntaxe de Lua 5.1
  • Il fournit en plus des extensions syntaxiques modernes et familières pour améliorer le confort de développement
  • La syntaxe complète est disponible dans la documentation Syntax

Analysis

  • Il fournit des outils d’analyse de scripts pour aider à écrire du code correct

  • Composants :

    • Linter : détection des erreurs courantes
    • Type Checker : validation des types

  • Ils peuvent être exécutés via l’outil CLI luau-analyze

  • Pour les règles de lint, voir la documentation Lint, et pour le typage, le guide Typecheck

Performance

  • Il fournit un frontend personnalisé incluant parseur, linter et vérificateur de types, ainsi qu’un bytecode optimisé, un interpréteur et un compilateur
  • Dans certains cas, les performances peuvent rivaliser avec celles de l’interpréteur LuaJIT
  • Un compilateur JIT manuel est pris en charge sur les plateformes x64 et ARM64, ce qui peut fortement améliorer les performances de certains programmes
  • Le runtime continue d’être optimisé et partiellement réécrit pour améliorer son efficacité
  • Les caractéristiques détaillées en matière de performances sont fournies dans la documentation Performance

Libraries

  • Le langage lui-même est un sur-ensemble complet de Lua 5.1
  • Dans la bibliothèque standard, certaines fonctions ont été retirées et d’autres ajoutées
  • Lorsqu’il est embarqué dans une application, il peut aussi accéder à des bibliothèques d’extension spécifiques à l’application
  • La documentation complète des bibliothèques est disponible dans la documentation Library

À lire aussi

1 commentaires

 
GN⁺ 2025-09-23
Commentaires sur Hacker News
  • Quelqu’un explique avoir utilisé Lua et LuaJIT dans Lumix Engine puis être passé à Luau à cause du système de types, tout en constatant qu’il est difficile de l’utiliser en dehors de Roblox : la documentation est insuffisante, la communauté est presque inexistante et n’aide pas du tout à résoudre les problèmes, la taille est plus importante que Lua ou LuaJIT, ce qui rend la compilation 7 fois plus lente, la gestion asynchrone de l’API est en pratique bloquée de façon synchrone, l’usage de la STL est aussi jugé peu pratique, et il rencontre souvent des bugs liés à l’analyse et au LSP, au point d’envisager d’autres alternatives
    • L’équipe Roblox répond qu’elle met désormais l’accent sur une utilisation plus simple de Luau en dehors de Roblox ; il est déjà employé avec succès dans divers contextes comme Remedy Entertainment (Alan Wake 2), Digital Extremes (Warframe) ou GIANTS Software (Farming Simulator 25). Jusqu’ici, les investissements et le support étaient surtout concentrés en interne chez Roblox, mais ils développent maintenant Lute, un runtime autonome à usage général, et veulent aussi élargir l’écosystème avec divers outils de développement basés sur Luau. C’est encore un stade précoce, mais ils investissent activement pour mieux prendre en charge les usages externes et des cas variés, car ils estiment qu’attirer davantage d’utilisateurs et de cas d’usage est essentiel à la bonne croissance de Luau
    • Une personne dit utiliser Luau pour l’intégralité du code de gameplay d’un jeu Unity, soit plus de 60 000 lignes. Elle aimerait que la documentation, surtout sur les intégrations personnalisées, soit améliorée, et estime que le nouveau système de types et le LSP ne s’accordent pas encore très bien. Elle s’inquiète un peu de la direction à long terme depuis le départ de zeux, mais apprécie beaucoup l’expérience de développement elle-même : le hot reload du code Luau est quasi instantané même pendant l’exécution du jeu, les projets C++ compilent rapidement, et le fait d’offrir un environnement sandbox pour le modding est un vrai plus. La communauté officielle sur Discord est aussi relativement active
    • Quelqu’un s’interroge : si la compilation est lente, pourquoi faut-il compiler du code dans un langage de script ? Il demande si cela désigne peut-être la compilation de la VM Luau elle-même
  • Le fait que Roblox développe un runtime Luau pour bureau dans un style Node.js est jugé vraiment intéressant : https://github.com/luau-lang/lute
    • Il existe déjà un runtime Luau plus abouti, Lune, utilisé pour des scripts de build et l’automatisation de fichiers Roblox place, et qui fonctionne de façon tout à fait satisfaisante pour cet usage
    • Un autre runtime autonome Luau existe aussi : Lune
  • Luau paraît bien plus complexe que Lua ; en se basant sur le code, Luau représente 120 000 lignes de C++ contre 14 000 lignes de C pour Lua 5.1. Selon un commentaire, dès qu’on ajoute un système de types progressif ou statique, cette complexité devient inévitable, et un système de types un minimum complet finit forcément par être plus gros qu’un langage de script dynamique
    • Lua, et dans une certaine mesure Luau, reste un petit langage du point de vue de l’apprentissage, indépendamment du nombre de lignes de code. Le runtime nécessaire à l’exécution ne dépend pas entièrement de l’Analysis. Analysis contient en réalité deux systèmes de types complets ; ces trois dernières années, un nouveau système de types a été développé pour corriger des limites fondamentales, et l’ancien devrait bientôt être retiré, ce qui permettrait de supprimer environ 30 000 lignes de code
    • Une autre personne dit ne pas considérer Lua ni Luau comme des langages petits ou simples, ni penser que cette complexité soit forcément nécessaire. Elle travaille sur Bau, un langage plus simple mais expressif, ainsi qu’une VM de style Lua ; ce type de petit langage revient aussi régulièrement sur Reddit : Bau, Bau VM, r/ProgrammingLanguages
    • Un autre avis estime que le typage statique ou progressif augmente bien la complexité, mais beaucoup moins qu’on ne l’imagine ; au contraire, les langages de script dynamiques peuvent parfois être plus complexes. Un vérificateur de types Hindley–Milner peut tenir sur une page de code, donc une complexité de 2 000 pages paraît excessive. H–M est déjà complet sans gérer les fonctions d’ordre supérieur, les génériques (polymorphisme paramétrique) ou les pointeurs nuls, permet une inférence globale, peut être étendu, et avec sa base seule reste bien plus puissant qu’un système de types de C ou Java 1.7
    • Quelqu’un qui a déjà écrit lui-même un vérificateur de types pour Lua et beaucoup lu le code source note que les 14 000 lignes de Lua sont extrêmement denses ; avec un style plus ordinaire, cela ferait plutôt 30 à 40 000 lignes. En d’autres termes, Lua n’est pas intrinsèquement petit, il est surtout écrit de manière très concise
    • En détaillant davantage les chiffres donnés par tokei, le répertoire Analysis compte 62 000 lignes de C++, 9 200 lignes d’en-têtes C, Ast 8 400 lignes de C++, CodeGen 21 000 lignes de C++, etc., tandis que Lua 5.1 totalise 11 000 lignes de C et 1 900 lignes d’en-têtes sur l’ensemble du répertoire src
  • Quelqu’un demande la différence entre Teal et Luau, tous deux présentés comme des « dialectes Lua à typage statique » : https://teal-language.org/
    • Teal compile les fichiers Teal vers Lua, avec les mêmes avantages et inconvénients que la relation entre JS et TS. Luau, lui, dispose de son propre runtime compatible ascendant avec Lua, et n’améliore pas seulement le système de types mais l’expérience de développement dans son ensemble. Les deux approches sont donc assez différentes : Teal a l’avantage de fonctionner partout où Lua est disponible, tandis que Luau ne tourne que sur son runtime dédié, mais sans étape de compilation séparée, ce qui peut offrir une meilleure ergonomie pour les développeurs, tout en conservant et exploitant les informations de type
    • Teal est transpillé vers Lua, alors que Luau est un fork de Lua ; il peut donc faire évoluer largement les performances de l’interpréteur, la sécurité, l’extensibilité syntaxique, etc. Roblox est en outre une entreprise assez grande pour approcher les 100 milliards de dollars de capitalisation boursière, avec plusieurs développeurs dédiés à plein temps
    • Luau n’est pas juste « Lua avec des types » : il mise fortement sur un système de types progressif et l’inférence de types, tout en faisant évoluer progressivement le langage lui-même. Il est conçu autour de l’expérience développeur et du support outillage ; la taille du binaire reste prise en compte, mais la simplicité stricte de Lua n’est pas sa priorité absolue. L’objectif est moins d’intégrer Lua à de grands projets C que d’offrir directement une bonne expérience aux développeurs dans le langage lui-même
  • Certains regrettent que Lua n’ait pas davantage évolué tout en préservant la compatibilité avec le passé. À la fin des années 2000, Roblox et d’autres projets ont adopté Lua 5.1 ; Lua en est aujourd’hui à la version 5.4, mais la compatibilité avec les anciennes versions n’a pas été très bien maintenue. LuaJIT, par exemple, ne prend en charge que la 5.1. La situation est comparée à Python 2.x/3.x, sauf que la communauté Lua a plutôt tendance à continuer d’utiliser massivement la 5.1
    • Selon une réponse, c’est même pire : luau et luaJIT ont eux aussi divergé du projet lua officiel dans des directions différentes, au point d’être désormais subtilement incompatibles entre eux. Tous viennent d’une branche Lua 5.1, mais il semble qu’il n’y ait plus vraiment de standard officiel partagé
    • La grande différence, c’est que la communauté Lua ne blâme pas publiquement la rupture de compatibilité descendante, ce qui rend finalement assez facile l’écriture de code pour différentes versions
    • Il est difficile d’obtenir des statistiques officielles, mais d’après un ressenti personnel, les utilisateurs de 5.1 et 5.2 seraient plus nombreux que ceux de 5.4, et peut-être même de 5.3 ; LuaJIT suscite de l’intérêt, mais se voit en pratique moins souvent qu’on pourrait le croire
    • LuaJIT inclut aussi certaines fonctionnalités des versions plus récentes de Lua (5.2, 5.3), ainsi que d’autres extensions : https://luajit.org/extensions.html
  • Ce qui a le plus intrigué une personne, c’est que l’interpréteur Luau puisse parfois rivaliser avec LuaJIT ; la page sur les performances est jugée très bien expliquée et témoigne du niveau d’ingénierie chez Roblox : https://luau.org/performance
  • Une personne a découvert Luau parce que son enfant de 13 ans s’est intéressé à Roblox Studio et a aussi visité luau.org ; l’ingénierie de Roblox lui paraît vraiment impressionnante
    • Arseny Kapoulkine est cité comme un ingénieur exceptionnel ; on recommande de suivre son blog ou ses réseaux sociaux. En plus de luau et du moteur de rendu de Roblox, il a créé meshoptimizer, une bibliothèque quasiment incontournable dans l’industrie graphique, et volk est même intégré au Vulkan SDK
  • Second Life est en train de passer de son ancien Linden Scripting Language à Luau. Auparavant, la compilation reposait sur Mono, mais Mono n’étant plus maintenu, un nouveau langage est devenu nécessaire. En plus du support de Luau, l’ancien compilateur LSL a été modifié pour cibler le moteur d’exécution Luau. Les performances s’améliorent aussi légèrement. Second Life constitue un environnement particulier où des centaines de milliers de scripts événementiels tournent sur les serveurs ; la gestion des ressources y est délicate, car si des programmes inactifs consomment chacun 1 microseconde par frame, l’accumulation devient vite problématique
    • Quelqu’un dit avoir testé lui-même l’environnement bêta de Luau à son ouverture et avoir nettement ressenti une amélioration des performances par rapport à l’ancien système Mono. En particulier, lors de l’enregistrement (Save), la vérification des scripts est passée d’environ 10 secondes à un résultat quasi instantané, ce qui améliore fortement l’efficacité du développement. Il aimerait toutefois disposer, comme dans FiveM, de fonctions utilitaires pour manipuler facilement les coroutines, telles que CreateThread(fn), Wait(ms), ainsi que de fonctionnalités Await/Promises (implémentation Luau de Promise). Dans FiveM, ce type d’enveloppe facilite l’optimisation des scripts et la gestion des coroutines : exemple du scheduler Lua de FiveM
    • Après le changement de VM, ce qui saute immédiatement aux yeux est que l’overhead précédent se situait surtout dans l’ordonnancement, les changements de contexte et l’implémentation des fonctions de bibliothèque. Luau prend naturellement en charge l’ordonnancement préemptif par sa conception, ce qui simplifie beaucoup la coordination d’un simple code glue. Le faire directement au niveau de la VM est bien moins coûteux et plus facile à implémenter qu’une transformation en machine à états au niveau de l’AST ou du bytecode ; même l’overhead de quelques microsecondes des programmes inactifs reste au fond un problème que le scheduler doit optimiser
  • Certains trouvent que l’attrait minimaliste de Lua a été en partie abîmé par l’inférence de types, même si c’est le prix à payer pour la sûreté de type. Une personne raconte avoir été surprise de voir qu’après avoir déclaré --!strict, le code s’exécutait quand même sans aucune erreur ni avertissement malgré une violation de type évidente, ce qui ne correspondait pas à ses attentes
    • Il est expliqué que le système de types actuel de Luau n’est pas « obligatoire » au sens strict : on peut exécuter du code sans vérification de types, et si l’on lance directement le code avec la démo ou l’exécutable luau, le contrôle de types ne s’applique pas. En revanche, dans un environnement embarqué qui forcerait la vérification de types de tout le code avant compilation, on obtiendrait bien l’expérience attendue avec détection des erreurs de type. Ce choix de conception était inévitable étant donné que des millions de lignes de Lua 5.1 ont dû être migrées vers Luau d’un seul tenant
  • Quelqu’un dit avoir toujours voulu un Typed Lua, mais que l’implémentation complète d’un vérificateur de types et d’un LSP pour un langage dynamique est assez difficile. Chaque langage dynamique rencontre des problèmes similaires de typage structurel, comparables à ceux vus dans TypeScript. Il se demande donc s’il ne serait pas possible de réutiliser le moteur de TypeScript, de convertir partiellement du code Luau en TypeScript, de faire la vérification avec tsc, puis de remapper les erreurs et résultats vers Luau, afin de créer plus rapidement des vérificateurs de types pour divers langages dynamiques
    • De même que LLVM sert d’IR commun pour les compilateurs, on pourrait imaginer le système de types TypeScript comme backend commun sous la forme d’un « langage intermédiaire » pour les systèmes de types. Cette personne n’apprécie pas particulièrement les langages dynamiques, mais s’y intéresserait davantage s’ils pouvaient bénéficier d’un niveau de vérification et d’outillage comparable à TypeScript. Ce qui ne peut pas être vérifié pourrait simplement être laissé de côté, ce qui correspond selon elle à la nature même du typage progressif. Si le système de types de TypeScript existait dans un runtime Lua, elle l’essaierait volontiers, et suit donc de près l’évolution de Luau
    • Il existe déjà un excellent Luau Language Server, qui offre dans vscode, nvim, zed et d’autres environnements de très bons diagnostics, l’autocomplétion et une vérification de types stricte. L’expérience de développement est jugée bien meilleure que ce que cette personne a connu avec Ruby ou Python. Elle utilise Luau pour le shell scripting comme pour de la programmation plus générale, et a même créé son propre runtime de style node, seal ; les développeurs Roblox, eux, utiliseraient plus souvent Lune pour le CI/CD, les tests, etc.
    • Un autre commentaire estime que pousser TypeScript à typer tous les recoins d’un langage dynamique rend le système trop complexe ; il vaudrait mieux, comme ReScript ou Gleam, imposer quelques restrictions au langage cible et s’appuyer sur un système de types Hindley–Milner. Ce dernier bénéficie d’une longue histoire théorique et pratique, ce qui le rend solide et utile. La personne trouve d’ailleurs surprenant qu’il n’existe pas de petit projet de langage de la famille ML compilant vers lua ; Gleam irait très bien avec un backend Lua
    • Un projet existe déjà : TypeScriptToLua, avec un retour d’expérience plutôt positif sur Love2D