Luau – bahasa skrip berbasis Lua yang cepat, kecil, aman, dan memiliki tipe gradual

• Luau adalah bahasa skrip embedded yang cepat, aman, dan mendukung tipe gradual, diturunkan dari Lua 5.1
• Bahasa ini berkembang dengan peningkatan pada performa, alat bantu bahasa, dan sistem tipe untuk mendukung game kompleks dan codebase berskala besar di platform Roblox
• Tidak seperti Lua standar, Luau memiliki fitur sandboxing sehingga kode dengan tingkat hak akses berbeda dapat berjalan berdampingan
• Sintaksnya kompatibel dengan Lua 5.1, tetapi menyediakan ekstensi sintaks tambahan dan alat analisis (linter, type checker) untuk meningkatkan kualitas kode
• Dengan optimasi performa, bytecode kustom, dukungan JIT, dan lainnya, Luau menargetkan kecepatan eksekusi setara LuaJIT serta memiliki potensi besar untuk digunakan di berbagai lingkungan embedded di luar Roblox

---

Motivation (latar belakang)

• Sekitar tahun 2006, Roblox mengadopsi Lua 5.1 sebagai bahasa scripting untuk game
• Seiring waktu, tingkat kompleksitas game di platform Roblox meningkat dan ukuran tim membesar, sehingga bahasa dan implementasinya ditingkatkan secara besar-besaran untuk mengatasi keterbatasan Lua lama
• Sejalan dengan pertumbuhan platform, banyak investasi dilakukan pada optimasi performa, kemudahan penggunaan, dan pengembangan tool terkait bahasa
• Secara khusus, saat mengelola codebase skala besar dengan lebih dari 1 juta baris kode pada 2020, mereka menyadari bahwa penerapan sistem tipe gradual menjadi hal yang esensial
• Berdasarkan kebutuhan ini, Roblox mengembangkan bahasa turunan dari Lua bernama Luau, yang menyediakan kemampuan untuk menjadi cepat, kecil, aman, sekaligus memungkinkan penerapan tipe secara gradual
• Penjelasan lebih rinci tersedia di dokumen Why Luau

Ikhtisar Luau

• Luau adalah bahasa skrip embedded berbasis Lua 5.1
  • Menyediakan runtime yang cepat dan ringan
  • Mendukung sistem tipe gradual sehingga analisis dinamis dan statis dapat digunakan bersamaan
• Terintegrasi ke Roblox Studio, dan mode strict dapat diaktifkan dengan flag --!strict
• Developer dapat melihat dokumentasi yang terhubung dengan Roblox di Luau Creator Docs

Sandboxing (fitur sandbox)

• Luau membatasi pustaka standar yang diekspos dan menyediakan fitur sandboxing tambahan
• Dengan ini, kode non-privileged yang ditulis developer umum dan kode privileged internal platform dapat dijalankan secara paralel dengan aman
• Karena itu, lingkungan eksekusinya berbeda dari Lua standar
• Detail lebih lanjut dapat dilihat pada penjelasan Sandbox

Compatibility (kompatibilitas)

• Sebisa mungkin mempertahankan kompatibilitas mundur dengan Lua 5.1, sambil juga mengadopsi sebagian fitur dari versi yang lebih baru
• Namun, Luau tidak menerima semua keputusan desain Lua, melainkan mencerminkan use case dan batasan khas Roblox
• Status dukungan fitur dari versi setelah Lua 5.1 tersedia di dokumen Compatibility

Syntax (sintaks)

• Sepenuhnya kompatibel dengan sintaks Lua 5.1
• Selain itu, menyediakan ekstensi sintaks yang modern dan familier untuk meningkatkan kenyamanan pengembangan
• Sintaks lengkap dapat dilihat di dokumen Syntax

Analysis (alat analisis)

• Menyediakan alat analisis skrip untuk membantu menulis kode yang benar

• Komponennya:

  • Linter: mendeteksi kesalahan umum
  • Type Checker: memverifikasi tipe

• Dapat dijalankan melalui tool CLI luau-analyze

• Untuk aturan lint lihat dokumen Lint, dan untuk panduan type checking lihat dokumen Typecheck

Performance (performa)

• Menyediakan frontend kustom yang mencakup parser, linter, dan type checker, serta bytecode, interpreter, dan compiler yang dioptimalkan
• Dalam beberapa kasus, performanya dapat bersaing dengan interpreter LuaJIT
• Mendukung compiler JIT manual pada platform x64 dan ARM64, yang dapat sangat meningkatkan performa program tertentu
• Runtime terus dioptimalkan dan sebagian komponennya ditulis ulang untuk meningkatkan efisiensi
• Karakteristik performa secara rinci tersedia di dokumen Performance

Libraries (pustaka)

• Bahasa ini sendiri merupakan superset penuh dari Lua 5.1
• Pada pustaka standar, beberapa fungsi dihapus dan beberapa fungsi baru ditambahkan
• Saat di-embed ke dalam aplikasi, bahasa ini juga dapat mengakses pustaka ekstensi khusus aplikasi
• Dokumentasi pustaka lengkap tersedia di dokumen Library

[GN⁺]

Komentar Hacker News

• Saya pernah menggunakan Lua dan LuaJIT di Lumix Engine lalu beralih ke Luau karena sistem tipenya, tetapi saya merasa sulit memakainya di proyek di luar Roblox; dokumentasinya kurang baik dan komunitasnya hampir tidak ada, sehingga sama sekali tidak membantu saat memecahkan masalah. Ukurannya juga lebih besar dibanding Lua atau LuaJIT, sehingga kompilasinya 7 kali lebih lambat. Penanganan asinkron di API juga pada praktiknya terblokir secara sinkron, dan ada banyak hal yang terasa tidak nyaman seperti penggunaan STL. Saya juga sering mengalami bug terkait analisis dan LSP, jadi saya sedang mempertimbangkan apakah perlu mencari alternatif lain.
  • Tim Roblox saat ini berfokus agar Luau ke depan bisa lebih mudah dimanfaatkan di luar Roblox juga. Luau sudah dipakai dengan baik di berbagai tempat seperti Remedy Entertainment (Alan Wake 2), Digital Extremes (Warframe), dan GIANTS Software (Farming Simulator 25). Sejauh ini investasi dan dukungan memang terpusat di dalam Roblox, tetapi ke depan mereka sedang mengembangkan Lute, runtime mandiri untuk penggunaan umum di luar Roblox. Mereka juga ingin memperluas ekosistem dengan membuat berbagai alat pengembang berbasis Luau. Ini memang masih tahap awal, tetapi mereka sedang aktif berinvestasi sambil mendukung penggunaan eksternal dan berbagai kasus pemakaian. Mereka percaya bahwa untuk pertumbuhan Luau yang sehat, penting untuk menarik lebih banyak pengguna dan contoh pemanfaatan.
  • Saya menggunakan Luau untuk seluruh kode gameplay game Unity saya (lebih dari 60 ribu baris). Saya berharap dokumentasinya, khususnya soal integrasi kustom, bisa diperbaiki. Sistem tipe baru dan LSP juga masih terasa kurang cocok satu sama lain. Setelah zeux meninggalkan tim, saya agak khawatir soal arah jangka panjangnya. Namun, pengalaman pengembangannya sendiri sangat saya sukai. Kode Luau bisa di-hot reload hampir seketika bahkan saat game sedang berjalan, dan proyek C++ juga bisa dikompilasi dengan cepat. Saya juga suka karena ada lingkungan sandbox untuk mendukung modding. Komunitas Discord resminya juga cukup aktif.
  • Katanya kompilasinya jadi lebih lambat, tapi kalau ini bahasa skrip bukankah seharusnya tidak perlu mengompilasi kode? Saya penasaran apakah yang dimaksud adalah kompilasi VM Luau itu sendiri.
• Sangat menarik bahwa Roblox sedang mengembangkan runtime Luau desktop bergaya Node.js: https://github.com/luau-lang/lute
  • Sebenarnya sudah ada runtime Luau yang lebih matang, yaitu Lune. Saya memakainya untuk skrip build dan otomatisasi file Roblox place, dan untuk kebutuhan saya sejauh ini kerjanya sangat memuaskan.
  • Ada juga runtime Luau mandiri lain bernama Lune.
• Luau tampaknya jauh lebih kompleks daripada Lua. Jika dilihat dari basis kodenya, Luau memiliki 120 ribu baris C++, sedangkan Lua 5.1 hanya 14 ribu baris C. Saya rasa kompleksitas semacam itu memang sulit dihindari ketika menambahkan sistem tipe gradual atau statis. Kalau ada sistem tipe yang cukup lengkap, pada akhirnya ukurannya memang sulit untuk tidak lebih besar daripada bahasa skrip dinamis.
  • Lua (dan sampai batas tertentu Luau juga) tergolong kecil bukan dari jumlah baris kodenya, melainkan dari sudut pandang mempelajari bahasanya sendiri. Runtime yang dibutuhkan untuk eksekusi tidak harus sepenuhnya bergantung pada Analysis. Di dalam Analysis ada dua sistem tipe lengkap, dan selama 3 tahun terakhir mereka mengembangkan sistem tipe baru untuk mengatasi keterbatasan mendasar. Yang lama akan segera disingkirkan, dan itu saja bisa mengurangi sekitar 30 ribu baris kode.
  • Saya tidak menganggap Lua maupun Luau sebagai bahasa yang kecil atau sederhana. Kompleksitas itu juga belum tentu diperlukan. Saya sedang mengerjakan bahasa bernama Bau yang lebih sederhana tetapi tetap ekspresif, sekaligus mengembangkan VM bergaya Lua. Bahasa-bahasa kecil seperti ini juga cukup sering jadi topik di Reddit: Bau, Bau VM, r/ProgrammingLanguages
  • Static typing atau gradual typing memang menambah kompleksitas, tetapi kenaikannya sering kali lebih kecil dari yang dibayangkan. Bahkan kadang bahasa skrip dinamis justru lebih kompleks. Type checker Hindley–Milner bisa diimplementasikan hanya dalam satu halaman kode, jadi kompleksitas setingkat 2.000 halaman seperti yang sedang dibahas ini terasa berlebihan. H–M sudah lengkap bahkan tanpa menangani higher-order function, generic (parametric polymorphism), atau null pointer, dan tetap memungkinkan inferensi penuh. Sistem ini juga bisa diperluas, dan bahkan dalam bentuk dasarnya saja jauh lebih kuat daripada sistem tipe C atau Java 1.7.
  • Saya pernah menulis type checker untuk Lua sendiri dan juga banyak membaca source code-nya. Angka 14 ribu baris pada Lua itu kepadatan kodenya sangat tinggi; kalau ditulis dengan gaya yang lebih umum, ukurannya mungkin jadi sekitar 30–40 ribu baris. Artinya Lua bukan kecil secara inheren, melainkan ditulis dengan sangat ringkas.
  • Jika jumlah baris yang dianalisis dengan tokei diurai lebih rinci, direktori Analysis berisi 62 ribu baris C++, header C 9.200 baris, Ast 8.400 baris C++, CodeGen 21 ribu baris C++, dan seterusnya. Sementara Lua 5.1 di seluruh src memiliki 11 ribu baris kode C dan 1.900 baris header.
• Saya penasaran apa bedanya Teal dan Luau. Keduanya sama-sama diperkenalkan sebagai "dialek Lua bertipe statis", jadi saya ingin membandingkannya: https://teal-language.org/
  • Teal mengompilasi file Teal menjadi Lua, jadi semua kelebihan dan kekurangan hubungan seperti JS dan TS juga berlaku di sini. Luau memiliki runtime sendiri yang kompatibel sebagai superset dari Lua, dan tidak hanya sistem tipenya yang ditingkatkan, tetapi juga pengalaman pengembangannya secara keseluruhan. Jadi keduanya cukup berbeda. Teal punya keunggulan bisa memakai Lua di mana saja, sedangkan Luau hanya berjalan di runtime khusus Luau. Namun, karena tidak ada tahap kompilasi terpisah, dari sudut pandang pengembang pengalaman pakainya bisa lebih baik. Informasi tipe juga tidak dibuang begitu saja dan tetap bisa dimanfaatkan.
  • Teal ditranspilasi ke Lua, sedangkan Luau adalah fork dari Lua. Karena itu, ia bisa berubah jauh lebih luas dalam hal performa interpreter, keamanan, extensibility sintaks, dan sebagainya. Roblox sendiri sangat besar, dengan kapitalisasi pasar mendekati 100 miliar dolar, dan ada beberapa pengembang khusus yang terus mengerjakannya.
  • Luau bukan sekadar "Lua yang ditambah tipe". Luau memberi perhatian besar pada sistem tipe gradual dan inferensi tipe, sambil terus memperbaiki bahasanya secara bertahap. Desainnya berpusat pada pengalaman pengembang dan dukungan tooling; ukuran biner memang diperhatikan, tetapi tidak menempatkan kesederhanaan ketat seperti Lua sebagai prioritas utama. Fokusnya lebih pada memberi pengalaman yang baik bagi pengembang yang langsung menulis dalam bahasa itu, bukan terutama untuk mengikat proyek C besar ke Lua.
• Sangat disayangkan Lua tidak berevolusi sambil mempertahankan kompatibilitas yang lebih baik dengan masa lalu. Pada akhir 2000-an, Roblox dan banyak proyek lain mengadopsi Lua 5.1, dan sekarang Lua sudah sampai 5.4, tetapi kompatibilitas dengan versi lama tidak terjaga dengan baik. LuaJIT dan sebagainya juga hanya mendukung 5.1. Ini mirip situasi Python 2.x/3.x, tetapi komunitas Lua tampaknya cenderung tetap memakai 5.1.
  • Sebenarnya bahkan lebih parah. Luau dan luaJIT juga berkembang ke arah masing-masing yang berbeda dari proyek lua resmi, sehingga sekarang ada ketidakcocokan halus di antara semuanya. Semuanya memang bercabang dari Lua 5.1, tetapi sekarang rasanya seolah tidak ada lagi standar resmi yang benar-benar dominan.
  • Perbedaan besarnya adalah komunitas Lua tidak secara terbuka mencela soal menjaga kompatibilitas ke belakang, sehingga menulis kode untuk berbagai versi berbeda justru cukup mudah.
  • Sulit mendapatkan statistik resmi, tetapi berdasarkan kesan saya pengguna 5.1 dan 5.2 tampaknya lebih banyak daripada 5.4, dan mungkin juga lebih banyak daripada 5.3. LuaJIT memang banyak menarik perhatian, tetapi tidak terlalu sering terlihat dipakai langsung.
  • LuaJIT juga memasukkan sebagian fitur dari versi Lua yang lebih baru (5.2, 5.3) dan punya lebih banyak fitur lagi: https://luajit.org/extensions.html
• Hal yang paling menarik bagi saya adalah bahwa interpreter Luau kadang bisa menyaingi LuaJIT. Halaman performanya menjelaskan ini dengan baik dan benar-benar memperlihatkan kemampuan engineering Roblox: https://luau.org/performance
• Saya mengenal Luau ketika anak saya yang berusia 13 tahun mulai tertarik pada Roblox Studio, lalu saya juga mengunjungi luau.org. Engineering Roblox benar-benar mengesankan.
  • Arseny Kapoulkine adalah engineer yang luar biasa. Sangat layak mengikuti blog atau SNS-nya. Selain Luau dan rendering engine Roblox, dia juga membuat meshoptimizer, yang nyaris wajib ditemui di industri grafis, dan volk bahkan sampai disertakan dalam Vulkan SDK.
• Second Life sedang beralih dari Linden Scripting Language ke Luau. Sebelumnya mereka memakai kompilasi berbasis Mono, tetapi karena Mono tidak lagi dipelihara, mereka membutuhkan bahasa baru. Tidak hanya menambahkan dukungan Luau, mereka juga mengubah kompiler LSL lama agar menargetkan mesin eksekusi Luau. Performanya juga sedikit meningkat. Second Life punya lingkungan unik dengan ratusan ribu skrip berbasis event berjalan di server, jadi pengelolaan resource tidak mudah; jika program yang tidak aktif memakai 1 mikrodetik setiap frame, akumulasinya bisa menjadi masalah besar.
  • Saat lingkungan beta Luau dibuka, saya mencobanya sendiri dan langsung merasakan peningkatan performa besar dibanding sistem Mono lama. Khususnya, kecepatan pemeriksaan skrip saat Save turun dari 10 detik menjadi seketika, sehingga efisiensi pengembangan meningkat drastis. Namun, akan lebih baik kalau ada helper function seperti CreateThread(fn), Wait(ms) untuk menangani coroutine dengan mudah seperti di FiveM, serta fitur Await/Promises (implementasi Luau Promise). Di FiveM, wrapper seperti ini sangat membantu optimisasi skrip dan pengelolaan coroutine: contoh scheduler Lua FiveM
  • Setelah VM diganti, hal yang langsung terlihat adalah bahwa overhead sebelumnya banyak berasal dari scheduling, context switch, dan implementasi fungsi library. Luau secara desain mendukung preemptive scheduling dengan alami, sehingga pengaturan glue code sederhana jadi jauh lebih mudah. Menangani ini di level VM jauh lebih murah dan lebih mudah diimplementasikan daripada mengubahnya menjadi state machine di level AST atau bytecode. Overhead idle program dalam satuan mikrodetik pada akhirnya juga merupakan sesuatu yang harus dioptimalkan oleh scheduler.
• Ada sisi di mana daya tarik minimalis Lua asli terasa rusak karena type inference, meskipun itu memang pertukaran dengan type safety sehingga ada plus minusnya. Namun, saya sempat kaget ketika setelah mendeklarasikan --!strict, kode tetap berjalan tanpa error atau warning sama sekali meski ada pelanggaran tipe yang jelas. Itu berbeda dari perilaku yang saya harapkan.
  • Saat ini sistem tipe Luau belum bersifat "wajib (strict)". Kode masih bisa dijalankan tanpa type checking, dan jika dijalankan langsung lewat demo atau executable luau, pemeriksaan tipe tidak diterapkan. Kalau di lingkungan embedded semua kode dipaksa menjalani type checking sebelum kompilasi, maka Anda bisa mendapatkan pengalaman sesuai harapan, yaitu type error tertangkap. Ini merupakan desain yang nyaris tak terhindarkan karena mereka memindahkan jutaan baris kode Lua 5.1 ke Luau sekaligus.
• Saya selalu menginginkan Typed Lua, tetapi ternyata cukup sulit membuat type checker dan LSP yang benar-benar lengkap untuk bahasa dinamis. Setiap bahasa dinamis punya masalah structural typing yang mirip-mirip, seperti yang terjadi di TypeScript. Saya jadi penasaran, kalau engine TypeScript dipakai ulang, kode Luau diubah sebagian menjadi TypeScript lalu diperiksa dengan tsc, dan setelah itu error/hasilnya dipetakan kembali ke Luau, apakah itu bisa menjadi cara cepat membuat type checker untuk berbagai bahasa dinamis?
  • Seperti LLVM yang menjadi IR umum untuk compiler, mungkin TypeScript type system juga bisa dipakai sebagai backend umum berupa "bahasa perantara" untuk sistem tipe. Saya pribadi tidak terlalu menyukai bahasa dinamis, tetapi kalau ada type checking dan dukungan tooling setara TypeScript, minat saya akan jauh lebih besar. Bagian yang tidak bisa didukung ya bisa dilepas saja, dan menurut saya itulah inti dari gradual typing. Jika sistem tipe TypeScript hadir di runtime Lua, saya pasti tertarik memakainya. Saya juga sangat mengikuti arah perkembangan Luau.
  • Luau sudah punya Luau Language Server yang sangat bagus, sehingga di vscode, nvim, zed, dan lainnya kita mendapatkan diagnostik, autocomplete, dan type checking ketat yang sangat baik. Pengalaman pengembangannya jauh lebih baik daripada yang saya rasakan di Ruby atau Python. Saya memakai Luau untuk shell scripting maupun pemrograman umum, dan juga membuat runtime sendiri bergaya node bernama seal. Sementara itu, para pengembang Roblox katanya lebih sering memakai Lune yang lebih populer untuk CI/CD, testing, dan sebagainya.
  • Kalau TypeScript dipaksa untuk mengetik setiap sudut bahasa dinamis, sistemnya akan menjadi terlalu kompleks. Karena itu saya rasa akan lebih baik mengambil pendekatan seperti Rescript atau Gleam, yaitu memberi beberapa batasan pada bahasa target lalu memakai sistem tipe Hindley–Milner. Sistem tipe HM terasa kuat dan praktis karena didukung pengalaman panjang serta teori yang matang. Secara pribadi saya justru heran belum ada proyek bahasa kecil keluarga ML yang menargetkan output ke Lua. Kalau Gleam mendukung backend Lua, rasanya akan sangat cocok.
  • Sudah ada proyek semacam itu, yaitu TypeScriptToLua. Saya pernah memakainya untuk Love2D dan pengalamannya cukup bagus.