Luau – 高速・軽量・安全で段階的型付けを備えたLuaベースのスクリプト言語

 (luau.org)
7 ポイント 投稿者 GN⁺ 2025-09-23 | 1件のコメント | WhatsAppで共有
  • Luauは、Lua 5.1から派生した高速で安全、かつ段階的型付けをサポートする埋め込みスクリプト言語
  • Robloxプラットフォームの複雑なゲームと大規模コードベースを支えるため、性能、言語ツール、型システムを強化しながら発展してきた
  • 標準のLuaとは異なり、サンドボックス機能を備え、権限の異なるコードを並行して実行できるよう設計されている
  • 構文はLua 5.1と互換性があるが、追加の構文拡張と**解析ツール（linter、型チェッカー）**を提供し、コード品質を高める
  • 性能最適化、カスタムバイトコード、JIT対応などにより、LuaJIT級の実行速度を目指しており、Robloxを超えてさまざまな埋め込み環境でも活用の可能性が高い

Motivation（登場背景）

  • 2006年ごろ、Robloxはゲームスクリプト言語としてLua 5.1を導入した
  • 時間の経過とともにRobloxプラットフォーム上のゲームの複雑さが増し、チーム規模も拡大したため、既存Luaの限界を克服すべく言語と実装を大幅に改善した
  • プラットフォームの成長に合わせて、性能最適化、使いやすさ、言語関連ツールの開発に多くの投資を行ってきた
  • 特に2020年時点で100万行を超える大規模コードベースを管理する中で、段階的型システムの導入が不可欠であると認識した
  • こうした必要性を背景に、RobloxはLuaから派生したLuauという言語を開発し、高速・軽量・安全でありながら段階的に型を適用できる機能を提供している
  • 詳細はWhy Luauを参照

Luau概要

  • LuauはLua 5.1をベースとする埋め込みスクリプト言語
    • 高速で軽量なランタイムを提供
    • 段階的型システムをサポートし、動的解析と静的解析を併用可能
  • Roblox Studioに統合されており、--!strictフラグで厳格モードを有効化できる
  • 開発者はLuau Creator DocsでRobloxと連携したドキュメントを確認できる

Sandboxing（サンドボックス機能）

  • Luauは公開される標準ライブラリを制限し、追加のサンドボックス機能を提供する
  • これにより、一般開発者が書いた非特権コードとプラットフォーム内部の特権コードを安全に並行実行できる
  • そのため、標準のLuaとは異なる実行環境を持つ
  • 詳細はSandboxの説明を参照

Compatibility（互換性）

  • 可能な限りLua 5.1との後方互換性を維持しつつ、以降のバージョンの機能も一部取り入れている
  • ただしLuauは、Luaのすべての設計判断を受け入れているわけではなく、Roblox特有のユースケースと制約を反映している
  • Lua 5.1以降の機能の対応状況はCompatibilityドキュメントで確認できる

Syntax（構文）

  • Lua 5.1の構文と完全互換
  • さらに、現代的で親しみやすい構文拡張を提供し、開発の利便性を高めている
  • 全体の構文はSyntaxドキュメントを参照

Analysis（解析ツール）

  • 正しいコード記述を支援するため、スクリプト解析ツールを提供

  • 構成要素:

    • Linter: 一般的なエラーを検出
    • Type Checker: 型を検証

  • luau-analyze CLIツールで実行できる

  • リントルールはLintドキュメント、型チェックのガイドはTypecheckドキュメントを参照

Performance（性能）

  • パーサー、リンター、型チェッカーを含むカスタムフロントエンドと、最適化されたバイトコード、インタープリタ、コンパイラを提供
  • 場合によってはLuaJITインタープリタと競合できる性能を発揮する
  • x64・ARM64プラットフォームで手動JITコンパイラをサポートし、特定のプログラム性能を大幅に向上させられる
  • 継続的にランタイムを最適化し、一部を書き直して効率を改善している
  • 性能の詳細はPerformanceドキュメントで提供されている

Libraries（ライブラリ）

  • 言語自体はLua 5.1の完全なスーパーセット
  • 標準ライブラリでは一部の関数を削除し、新しい関数も一部追加している
  • アプリケーションに組み込まれる際には、アプリ固有の拡張ライブラリにもアクセスできる
  • ライブラリ全体のドキュメントはLibraryドキュメントで確認できる

関連記事

1件のコメント

 
GN⁺ 2025-09-23
Hacker Newsの意見
  • Lumix EngineでLuaとLuaJITを使っていたが、型システムのためにLuauへ移行した経験がある。ただ、Roblox以外のプロジェクトでは使いにくいと感じた。ドキュメントが不十分でコミュニティもほぼなく、問題解決の助けがまったく得られない。LuaやLuaJITに比べてサイズが大きく、コンパイル速度は7倍遅くなった。APIの非同期処理も実質的には同期的に塞がれており、STLを使うなど不便な点が多い。解析やLSP関連のバグにも頻繁に遭遇しており、そのため別の代替案を探すべきか悩んでいる
    • Robloxチームは今後、LuauをRobloxの外でもより使いやすくすることに注力している。Remedy Entertainment(Alan Wake 2)、Digital Extremes(Warframe)、GIANTS Software(Farming Simulator 25)など、さまざまな場所ですでにうまく使われている。これまでは投資と支援がRoblox内部に集中していたが、今後は一般用途向けの独立ランタイムであるLuteを開発中で、さまざまなLuauベースの開発ツールも作ってエコシステムを広げようとしている。まだ初期段階だが、外部利用や多様なケースを支援しながら積極的に投資している。Luauの健全な成長のためには、より多様なユーザーと活用事例を呼び込むことが重要だと考えている
    • Unityゲームの全プレイコード(6万行以上)にLuauを使っている。ドキュメント、特にカスタム連携に関する内容が補強されてほしいし、新しい型システムとLSPもまだ相性があまり良くないと感じる。zeuxがチームを離れた後の長期的な方向性は少し心配ではある。ただ、開発体験そのものはとても気に入っている。Luauコードはゲーム実行中でもほぼ即時にホットリロードされ、C++プロジェクトもすばやくコンパイルできる。モッディング支援のためにサンドボックス環境を提供している点もよい。公式Discordコミュニティもそれなりに活発だ
    • コンパイルが遅くなると言っていたが、スクリプト言語なら本来コードをコンパイルする必要はないのではないかと疑問に思う。もしかしてLuau VM自体のコンパイルを意味しているのかと質問している
  • RobloxがNode.jsスタイルのデスクトップ向けLuauランタイムを開発中という点は本当に興味深い: https://github.com/luau-lang/lute
    • すでに完成度の高いLuauランタイムLuneがある。ビルドスクリプトやRoblox placeファイルの自動化作業に活用しており、自分の用途には十分満足できる動作をしている
    • もう1つの独立型LuauランタイムとしてLuneが存在する
  • LuauはLuaよりかなり複雑に見える。コードベースで見るとLuauはC++で12万行、Lua 5.1はCで1万4千行だ。漸進的または静的な型システムが入れば複雑になるのは避けられないと思う。ある程度完備した型システムがあれば、動的スクリプト言語より結局大きくならざるを得ない
    • Lua(そしてLuauもある程度)は、コード行数というより言語自体を習得する観点では小さい部類だ。実行に必要なランタイムはAnalysisに全面的に依存しなくてもよい。Analysisには2つの完全な型システムが入っているが、ここ3年ほど根本的な限界を解決するために新しい型システムを開発してきており、古いほうはまもなく取り除く予定だ。そうなればコードも3万行ほど減らせる
    • 私はLuaやLuauが小さい言語や単純な言語だとは思わない。複雑さが必ずしも必要とは限らない。Bauという、よりシンプルで表現力のある言語に取り組んでおり、LuaスタイルのVMも開発中だ。この手の小規模言語はRedditでもたびたび話題になる Bau, Bau VM, r/ProgrammingLanguages
    • 静的型付けや漸進的型付けは複雑さを増すが、その増加幅は思うほど大きくない。むしろ動的スクリプト言語のほうが複雑なことも多い。Hindley–Milner型チェッカーはコード1ページで実装できるのに、ここで話している2000ページ級の複雑さは過剰に感じる。H–Mは高階関数、ジェネリクス(パラメトリック多相性)、nullポインタも扱わなくても完結しており、全体推論が可能だ。拡張もでき、基本だけでもCやJava 1.7の型システムよりずっと強力だ
    • Luaの型チェッカーを自作し、ソースも多く読んできたが、Luaの1万4千行はコード密度が非常に高い。一般的なスタイルで書けば3〜4万行程度になる。つまりLuaは本質的に小さいというより、非常に簡潔に書かれている
    • tokeiで分析した行数をより細かく並べると、AnalysisディレクトリがC++ 6万2千行、Cヘッダー 9千2百行、AstはC++ 8千4百行、CodeGen C++ 2万1千行など。Lua 5.1はsrc全体でCコードが1万1千行、ヘッダーが1,900行だ
  • TealとLuauの違いが気になる。どちらも「静的型付きLua方言」と紹介されているので比較したい https://teal-language.org/
    • TealはTealファイルをLuaへコンパイルするので、JSとTSの関係のように長所と短所の両方が当てはまる。LuauはLuaとの上位互換を持つ独自ランタイムがあり、型システムだけでなく開発体験そのものを改善してくれる。したがって両者はかなり異なる。TealにはどこでもLuaを使える利点がある。一方でLuauはLuau専用ランタイムでしか動かないが、別途コンパイル段階がないため、開発者視点ではよりよい使い勝手が実現できる。型情報も捨てずに活用できる
    • TealはLuaへトランスパイルされるが、LuauはLuaのフォークだ。独自インタプリタの性能、セキュリティ、文法拡張性などを幅広く変えられる。Robloxは時価総額1000億ドル級の規模があり、専任開発者も複数常駐している
    • Luauは「Luaに型を足しただけ」ではなく、漸進的型システムと型推論に大きく力を入れ、言語自体も段階的に改良中だ。開発者体験とツール支援を中心に設計しており、バイナリサイズなども気にしてはいるが、Luaのような厳格な単純性を最優先にはしていない。大規模なCプロジェクトをLuaに結びつける用途より、開発者が言語そのものでよい体験を得ることに、より焦点を当てている
  • Luaがもっと過去との互換性を保ちながら進化できなかったのは残念だ。2000年代後半にRobloxをはじめ多くのプロジェクトがLua 5.1を採用し、現在Luaは5.4まで来ているが、旧バージョンとの互換性はあまりうまく維持されなかった。LuaJITなどは5.1しか対応していない。Python 2.x/3.xの状況に似ているが、Luaコミュニティは大半が今でも5.1を使い続ける傾向がある
    • 実際にはさらに深刻で、luauとluaJITも公式luaプロジェクトとはそれぞれ別方向に発展し、今では互いに微妙に互換性がない。いずれもLua 5.1から分岐したが、もはや公式標準がなくなったような感覚だ
    • 大きな違いは、Luaコミュニティは下位互換性の維持について公然と非難しないため、さまざまなバージョン向けにコードを書くのがかなり容易だということだ
    • 公式統計を得るのは難しいが、体感では5.1や5.2の利用者が5.4より多く、5.3も超えていない気がする。LuaJITは関心こそ高いが、実際にはそれほど頻繁には見かけない
    • LuaJITはLuaの新しいバージョン(5.2、5.3)の機能も一部取り込み、さらに多くの機能を持っている https://luajit.org/extensions.html
  • LuauインタプリタがLuaJITに匹敵する場合があるという点がいちばん興味深かった。性能ページに良い説明があり、Robloxのエンジニアリング力を感じる https://luau.org/performance
  • 13歳の子どもがRoblox Studioに興味を持ったことでLuauを知り、luau.orgも訪れてみた。Robloxのエンジニアリングは本当に印象的だ
    • Arseny Kapoulkineは優れたエンジニアだ。彼のブログやSNSをフォローするとよい。luauやRobloxのレンダリングエンジン以外にもmeshoptimizerを作っており、グラフィックス業界ではほぼ必須級に触れるライブラリだし、volkはVulkan SDKに含まれるほどだ
  • Second Lifeが既存のLinden Scripting LanguageからLuauへ移行中だ。以前はMonoベースのコンパイルだったが、Monoがもはや保守されていないため新しい言語が必要だった。Luau対応だけでなく、既存のLSLコンパイラがLuau実行エンジンをターゲットにするようにも変更された。パフォーマンスもわずかに改善した。Second Lifeは何十万ものイベント駆動スクリプトがサーバー上で動く独特な環境で、リソース管理が容易ではない。非アクティブなプログラムがフレームごとに1マイクロ秒使うだけでも、積み重なれば大きな問題になりうる
    • Luauベータ環境が公開されたときに実際に使ってみたが、従来のMonoシステムより性能が大幅に向上したと体感した。特に保存(Save)時のスクリプト検査速度が10秒から即時になり、開発効率が大きく上がった。ただ、FiveMのようにコルーチンを簡単に扱えるCreateThread(fn)、Wait(ms)のようなヘルパー関数やAwait/Promises機能があるとさらによいと思う(Luau Promise実装)。FiveMではこうしたラッパーのおかげでスクリプト最適化とコルーチン管理が容易になる。FiveMのLuaスケジューラ例
    • VMを変えたあとすぐに目立つのは、従来のオーバーヘッドの多くがスケジューリング、コンテキスト切り替え、ライブラリ関数実装にあった点だ。Luauは設計上プリエンプティブスケジューリングを自然に支援しており、単純なglue codeの調整がはるかに容易になる。VM上でこれを処理するほうが、ASTやバイトコード段階で状態機械へ変換するよりずっと安価で実装もしやすい。アイドル状態のプログラムのマイクロ秒単位のオーバーヘッドも、結局はスケジューラが最適化すべき対象だ
  • もともとのLuaのミニマルな魅力はtype inferenceのせいで少し損なわれている面があるが、型安全性とのトレードオフなので一長一短だ。ただ、--!strictを宣言したあとでも明らかな型違反が起きているのに、何のエラーや警告もなくコードが実行されて驚いた。期待した動作と違っていた
    • 現在のLuauの型システムは「必須(strict)」ではない。型チェックなしでコードを実行できるし、デモやluau実行ファイルで直接走らせても型チェックは適用されない。もし埋め込み環境で、すべてのコードに対してコンパイル前の型チェックを強制するようにすれば、期待どおり型エラーを捕まえる体験が得られる。これは数百万行のLua 5.1コードを一度にLuauへ移行したため、避けられない設計だ
  • Typed Luaはずっと欲しかったが、動的言語に型チェッカーとLSPを完全実装するのはかなり難しかった。動的言語ごとに似たような構造的型付けの問題があり(TypeScriptで経験する問題に近い)、もしTypeScriptエンジンを再利用してLuauコードも部分的にTypeScriptへ変換し、tscで検査したうえで再びエラーや結果をLuauへマッピングできれば、さまざまな動的言語向けに高速な型チェッカーを作れるのではないかと思う
    • まるでLLVMがコンパイラ向けの共通IRであるように、型システム用の「中間言語」としてTypeScript type systemを共通バックエンドにすることもできそうだ。私は動的言語を特に好むわけではないが、TypeScript並みの型検査とツール支援が得られるなら関心は高まる。うまくいかない部分は切り捨てればよく、それが漸進的型付けの本質だと思う。TypeScript型システムがLuaランタイムに入るならぜひ使ってみたいし、Luauの動向にも強い関心がある
    • Luauにはすでに優れたLuau Language Serverがあり、vscode、nvim、zedなどで優秀な診断、オートコンプリート、厳格な型チェックが使える。RubyやPythonで感じたものよりずっと良い開発体験だ。私はシェルスクリプティングや汎用プログラミングにLuauを使っており、sealというnode-styledの独自ランタイムも作った。Roblox開発者たちはCI/CDやテストには、より人気のあるLuneを使うらしい
    • TypeScriptで動的言語の隅々まで型付けしようとするとシステムが複雑になりすぎるので、RescriptやGleamのようにターゲット言語にある程度の制約を設け、Hindley–Milner型システムへ寄せるほうがよいと思う。HM型システムは長年の経験と理論の蓄積のおかげで堅牢かつ実用的だ。個人的には、Luaへコードを出力する小さなML系言語プロジェクトが存在しないのが意外だ。GleamがバックエンドとしてLuaをサポートしたら本当に相性が良さそうだ
    • すでに存在するプロジェクトとしてTypeScriptToLuaがある。Love2Dでかなり快適に使えた経験がある