Rearrange your action bars in World of Warcraft with an addon. Build a tycoon game on Roblox. Edit the config file for the Neovim text editor, or write a small rule that runs inside a Redis database. All four jobs run on the same little language, and most people doing them never give it a thought.
That language is Lua. It came out of a university in Rio de Janeiro in 1993, it has never had a big tech company behind it, and it still turns up inside game engines, routers, code editors and cheap Wi-Fi chips. Every couple of years someone writes that it's on the way out. Meanwhile, another studio ships a game built on it.
This piece is for people with a real decision to make: a founder choosing a stack for a game or a plugin-friendly app, a developer who just joined a team where "we script in Lua" is the house rule, or a writer or ops lead who keeps seeing the name. The question underneath is the same: is Lua still worth using for game scripting and embedded systems in 2027? I'll answer it directly, show how Lua behaves when things go wrong, and walk through the other options.
What Lua actually is
Most software has two layers. The bottom one is the heavy machinery: graphics, physics, networking, reading files. It has to be fast, so it's usually written in C or C++. The top layer is everything that changes every week. What a sword does. How a boss reacts when its health drops below half. Which button opens which menu. Changing that top layer in C++ means rebuilding the program, which on a large game can take anywhere from minutes to well over an hour.
A scripting language sits on top of the machinery. The engine offers commands like "spawn an enemy here" or "play this sound," and the script decides when to use them. You edit the script, reload it, and see the result in seconds.
Lua was made for exactly this. The whole interpreter (the program that reads and runs Lua code) is a few hundred kilobytes of plain C, so it compiles almost anywhere, from a gaming PC to a chip that costs less than a coffee. It has one main data structure, the table, which works as a list, a dictionary or an object depending on how you use it.
A few terms that come up later:
• Embedding means putting the Lua interpreter inside your own program. The game is the host and Lua is the guest.
• Garbage collection is Lua cleaning up unused memory automatically. Convenient, but the cleanup costs time, and in a game time is scarce.
• A JIT (just-in-time compiler) turns frequently used code into fast machine code while the program runs. LuaJIT, a separate version of Lua, does this.
• A sandbox is a fenced-off area where a script can only touch what you allow. It's how mod systems stop a player's script from deleting your files.
How Lua ended up inside so many games
Nobody marketed Lua. Studios in the late 1990s and 2000s needed a scripting layer and the other options were poor. Python was big and awkward to embed, and JavaScript engines of that era were slow and tied to browsers.
Lua was small, it came with the MIT license (you can ship it commercially without paying anyone or publishing your code), and C and Lua could pass data back and forth cleanly. LucasArts used it in Grim Fandango in 1998. World of Warcraft built its whole interface and addon system on it, which quietly turned a generation of players into programmers. CryEngine, Civilization V, Angry Birds, Don't Starve, Garry's Mod and Factorio's mod system followed. The LÖVE framework, also Lua, is what the card game Balatro was made with.
Then Roblox made it enormous. Roblox built its own version, called Luau, starting from Lua 5.1, and every experience on the platform is scripted in it.
Where Lua stands right now, in numbers
Lua has no company publishing adoption reports, so the clearest evidence comes from the platforms that depend on it.
So when a founder asks me is Lua still relevant 2027, my reply is that by raw usage it's more relevant than ever. It rarely shows up in "hottest languages" lists because those measure what developers talk about online, and most Lua lives inside finished products where nobody sees the name.
Why studios keep picking it
Small footprint, simple embedding
On a console or phone, memory is planned almost to the megabyte. A scripting runtime that eats 30 or 40 MB before the game loads a texture is a real cost. A fresh Lua environment (called a "state") with its standard libraries takes up tens of kilobytes, so you can run several side by side to keep systems apart.
Lua talks to C through something called the stack: the host pushes values on, calls a Lua function, and reads results back off. It feels clunky for a day or two, but it behaves identically on every platform. For C++ teams, binding libraries such as sol2 remove most of the tedium.
Designers can read it, and change it live
A line like if health < 20 then flee() end makes sense to someone who has never programmed. In many studios the people writing scripts are level designers and technical artists, not engineers, so readability saves engineering time.
Scripts are also loaded while the game runs, so you can change one and reload it without restarting. A designer tuning a boss fight can try ten versions in ten minutes.
Coroutines make "wait, then do" logic easy
Plenty of game logic follows a pattern: walk to the door, wait two seconds, open it, play a creak, wait for the player. In many languages that becomes a pile of flags and timers. Lua has coroutines, functions that can pause and pick up later from the same spot. A cutscene script can say wait(2) and the engine resumes it two seconds later. For quests and tutorials, that removes a whole category of bugs.
Pro tip: If you're adding Lua to a new C++ project, pick one version and write it into your project docs on day one. Lua 5.1, 5.4 and 5.5 differ in small ways that bite, such as number handling and how script environments work, and LuaJIT stays close to 5.1. Mixing libraries written for different versions causes some of the most confusing bugs you'll see.
How Lua behaves when real data hits it
What you really want to know is what happens when data is missing, when two parts of the game disagree, when you have 16 milliseconds to decide something, and when a server is full. This is where teams either settle in with Lua or start regretting it.
Data gaps: missing values and nil
In Lua, any variable or table field that hasn't been set is nil, meaning "nothing here." Reading a missing field doesn't crash. You just get nil back, which is forgiving and also where many bugs start.
Say a designer adds a new enemy to a config file and forgets the speed field. The script reads enemy.speed, gets nil, and hands it to the movement code. If that code is Lua, you get an error the moment it tries to do maths with nil. If nil is passed into C++ code that expects a number, the result depends on how carefully that connection was written. A sloppy one treats nil as zero, and now an enemy stands perfectly still and nobody knows why.
Save files have the same problem. Version 1.3 adds a "reputation" field, a player loads a save from 1.1, and the field isn't there.
Teams that have been burned by this usually:
• set up defaults with metatables, which are rule sets attached to a table. One rule, __index, says "if a field is missing, look here instead," so every config gets a fallback,
• validate when a level loads rather than when a value is used, because failing on the loading screen beats failing mid-boss-fight,
• stamp each save with a version number and write small migration functions that fill in anything added since.
One more trap catches nearly every new Lua programmer. The length operator, #, is only reliable for lists with no gaps. Set slot three of a five-slot inventory to nil and #inventory may return 5 or 2, and both follow the rules. Never use nil to mean "empty slot." Use false or a marker value.
Conflicting signals: when two scripts want different things
The combat script says the player is stunned. The cutscene script says the player can move. A mod says the player's speed is doubled. Which one wins?
Lua won't decide for you, because it's a language, not an architecture. What it does give you is a clear order of events. Each Lua state runs on a single thread, so two scripts in it never touch the same data at the same instant. That rules out race conditions (bugs where two threads change one value at once and the outcome depends on timing). It doesn't rule out logic conflicts.
Common fixes:
• Priority stacks. Instead of writing player.canMove = false, each system adds a request with a priority, and the final answer comes from all active requests. When the cutscene ends it removes its request, and the stun still applies.
• One owner per value. Only one system writes a given field; the rest send it messages.
• An event queue processed in a fixed order every frame, so results are repeatable.
Mod communities show the problem at its worst. Factorio loads mods in a set order and splits mod code into separate stages for defining game data and running logic. World of Warcraft tracks "taint," a record of whether addon code has touched something, so addons can't interfere with protected actions in combat. If users will script your product, design for conflicts before launch.
Hot reloading adds a twist. After a reload, old functions can still be held by timers or paused coroutines, so for a few seconds part of the game runs old logic. Teams that rely on reloading look up each callback by name when it fires, so one reload swaps logic everywhere.
Real-time decisions: the 16-millisecond budget
At 60 frames per second a game has about 16.7 milliseconds per frame for input, physics, AI, animation, audio and drawing. Scripts usually get a thin slice, often a couple of milliseconds on a console title.
Standard Lua is quick for an interpreted language, but for heavy number crunching it's often an order of magnitude or more slower than C++. LuaJIT closes much of that gap, and Luau can compile some scripts to native code.
What that means day to day:
• Lua decides and C++ does the work. A script decides an enemy should find cover; the pathfinding, which checks thousands of positions, runs in C++. Studios that ignore this split end up rewriting their slowest scripts later.
• Don't create new tables every frame. Each becomes garbage, and eventually a cleanup lands mid-frame and the game stutters.
• Cap runaway scripts. Lua's debug hook can fire every few thousand instructions, and engines use it as a watchdog. If a modder writes an infinite loop, the hook stops the script and logs an error instead of freezing the game.
Enemy AI shows the split done well: the behavior tree lives in C++, and Lua supplies rules like "if health is below 30 and an ally is nearby, retreat toward the ally."
Exceptions and edge cases
When something fails in Lua, the code raises an error that travels upward until something catches it with pcall (a "protected call") or xpcall, which also captures a stack trace. Most engines route every call from C++ into Lua through a protected call, so a broken script produces a log line, never a crash. That's why a broken WoW addon gives you an error popup instead of kicking you out.
The edge cases that catch teams out:
• Whole numbers versus decimals. Since Lua 5.3, a number can be an integer or a float. 7 // 2 gives 3 while 7 / 2 gives 3.5. Code written for Lua 5.1 or LuaJIT, where every number is a float, can behave slightly differently on 5.4 or 5.5.
• Automatic string conversion. Lua treats "10" as 10 in arithmetic, which is handy until a player types "10abc" into a chat command.
• Errors crossing into C++. By default a Lua error jumps back up the call chain using a C mechanism called longjmp. If that jump passes through C++ code, cleanup code may never run, leaking memory or leaving a lock held. Building Lua as C++ or using a good binding library avoids this.
• A leaky stack. If C code pushes values onto the Lua stack and forgets to remove them, the stack grows quietly until something breaks, sometimes hours into a session.
• Sandbox escapes. If users run their own scripts, strip out os.execute, io.open and the debug library. Never load precompiled bytecode from strangers, because Lua dropped its bytecode checker years ago.
Pro tip: Turn on a "strict mode" in development builds that raises an error whenever a script reads or writes an undeclared global variable. In older versions, a typo like playr.health = 0 quietly creates a new global. Lua 5.5 adds declarations for globals, but a strict mode catches the typo on any version.
Under pressure: memory, garbage collection and scale
Garbage collection is the biggest trade-off. Lua's collector has long worked incrementally, doing cleanup in small slices across many frames. Lua 5.4 added a generational mode that handles short-lived objects cheaply, and 5.5 makes the large full collections incremental too, so long pauses are less likely. Still, a game that throws away lots of tables every frame makes the collector work harder, and stutters appear on weaker hardware first. Many studios run a small collection step themselves at a fixed point each frame so the cost is predictable.
Memory budgets are easier than people expect. Lua lets the host supply its own memory allocator, so engines give each script system a budget and report exactly what scripts use. When a budget runs out, Lua raises an out-of-memory error and the engine can shut down the offending mod instead of crashing.
Threading is the other limit. One Lua state isn't safe to use from several threads at once, so to use multiple CPU cores you create separate states that pass messages. OpenResty, which runs Lua inside the Nginx web server, gives each worker process its own state, and that's how it handles very high traffic. Roblox's Parallel Luau does something similar by grouping scripts into isolated "actors" that run on different cores.
The pattern is consistent: Lua grows well by adding more small, separate states, and badly if one giant state does everything.
The alternatives, and who each one suits
Most roundups of Lua alternatives 2027 name roughly the same options. They aren't interchangeable, so here's where each one fits.
Luau
Roblox's version of Lua 5.1, open source since 2021. It adds gradual typing (you add type labels where you like and a checker flags mistakes before the code runs), better speed in many cases, and a sandbox designed for untrusted code. You can embed it in your own engine. Good for teams who like Lua but want types and strong isolation for user content.
LuaJIT
A very fast implementation of Lua 5.1 with an FFI, a feature that lets Lua call C functions directly without binding code. OpenResty and many PC games use it. Development is slow and it lacks newer Lua features. iOS and some consoles forbid generating machine code at runtime, so there it falls back to its interpreter, which is still quick.
Python
Huge ecosystem, widely known, and hard to embed well. The runtime is large, its global interpreter lock limits threading, and sandboxing it safely is widely considered unreliable. In studios it dominates tools (build scripts, Blender and Maya plugins) rather than in-game code.
JavaScript (QuickJS or V8)
Familiar to web developers. V8, Chrome's engine, is extremely fast but large and complex to embed. QuickJS is small, closer to Lua in size. A reasonable pick for interface-heavy products built by web teams.
C# and GDScript
In Unity your game logic is C#, and adding Lua is mostly worth it for mods or updating content without an app store release. Godot offers C# and GDScript, its own Python-like language. These are the main languages of those engines, not a light layer on top.
Squirrel, AngelScript and Wren
Smaller embeddable languages. Squirrel, used by Valve in Left 4 Dead 2 and Portal 2, works much like Lua with C-style syntax. AngelScript looks like C++ and uses static types. Wren has a clean class-based design. All capable, but with far smaller communities, so hiring and finding answers takes longer.
Unreal Blueprints and WebAssembly
Unreal leans on Blueprints, a visual system where you connect boxes instead of typing code, alongside C++. Some Unreal mobile teams still add Lua through plugins like Tencent's UnLua for fast patching. WebAssembly is the newest option: you compile Rust, C or other languages into a portable format and run it in a sandboxed runtime such as Wasmtime. Isolation is excellent and speed is near native, but game tooling is young and it offers designers nothing friendly to type into.
Side-by-side comparison
When a team shortlists Lua alternatives 2027 for a new project, a table like this ends the debate faster than a meeting. Chosen Unity? Use C#. In Godot? GDScript or C#. Building your own engine, or a C++ product that needs plugins? Lua or Luau is very hard to beat.
Lua outside games
A lot of Lua runs where most people never look. NodeMCU runs it on ESP8266 and ESP32 chips, the cheap Wi-Fi chips inside many hobby and small commercial smart devices. Redis runs Lua scripts inside the database so a group of operations happens as one step with nothing slipping in between. Kong, a popular API gateway, runs Lua on OpenResty. Neovim, Wireshark and Adobe Lightroom Classic all use it for plugins.
For hardware teams the question takes a different shape: is Lua still worth using for game scripting and embedded systems in 2027 now that MicroPython is so popular? On a chip with a few hundred kilobytes of memory, both work. MicroPython has a bigger community and more beginner guides. Lua is often lighter and simpler to drop into existing C firmware. If your firmware is already C and you want a small scripting layer for settings that change in the field, Lua is a sensible, boring choice, which on hardware is a compliment.
Devices bring their own edge cases. Memory is tighter, so garbage collection settings need more attention. Flash storage wears out, so avoid scripts that log constantly. And a script bug on a device in a warehouse can't show anyone an error box, so the firmware needs a watchdog that restarts the script or falls back to a known-safe version.
The weak spots you should plan for
• The standard library is tiny. No built-in networking, JSON or directory browsing. You depend on your host program or on LuaRocks, whose package catalog is much smaller than Python's or npm's.
• Versions are fragmented. Lua 5.1, LuaJIT, Luau, 5.4 and 5.5 are all in use, and libraries don't always work across them.
• Lists start at 1, not 0, which causes off-by-one mistakes where Lua and C meet.
• There are no types by default, so large codebases get hard to change safely. Luau's type checker, Teal (a typed Lua that converts to plain Lua) and the Lua Language Server all help.
• Deep experience is rarer than it looks. Plenty of developers have written Lua through Roblox or WoW. Far fewer have designed bindings, sandboxes and memory budgets for a shipping product.
None of this turns the answer to is Lua still relevant 2027 into a no. These are costs to plan and budget for before you commit.
A decision guide for founders and teams
Lua or Luau is a strong fit if:
• you have a C or C++ engine or app and want designers or users to script it,
• you want mod support or user-generated content,
• memory and startup time matter, as on mobile, consoles and small devices,
• you want to push content changes without shipping a new app build (store rules generally allow downloaded scripts that don't change what the app does, but check each store's current terms).
Look elsewhere if you've committed to Unity, Godot or Unreal, if your team is mostly web developers building an interface-heavy product, or if you need a large package ecosystem inside the scripting layer.
On cost: Lua is free, so the money goes into integration. A basic setup with a binding library can take a few days. A full mod system with sandboxing, memory budgets, error reporting and editor tooling can take an experienced engineer several weeks, and it needs an owner afterwards.
Reading about Lua alternatives 2027 can leave you thinking there's something better for everyone. For custom engines and C++ products that need a scripting layer, there usually isn't. If you're hiring a development partner to build a plugin system or game backend, ask how they'd handle sandboxing, memory limits and script errors in production. Their answers will tell you more than their favorite language.
So where does that leave Lua?
Lua has lasted because it does one narrow job very well and doesn't try to do anything else. It's small enough for a Wi-Fi chip, simple enough for a level designer, and dependable enough to run a platform used by over a hundred million people a day. Its weak spots, mainly garbage collection pauses, version splits and missing types, are well understood, and experienced teams have standard ways of handling each.
So, is Lua still worth using for game scripting and embedded systems in 2027? If you're building your own engine, a C++ product that needs plugins, a mod-friendly game or firmware that needs a small scripting layer, yes. People still searching is Lua still relevant 2027 tend to be looking at the wrong signal: talk online has faded, usage hasn't. If you live inside Unity, Godot or Unreal, use your engine's language and keep Lua in mind for modding. Either way, the choice comes down to how you'll handle missing data, conflicting scripts, frame budgets and errors, and Lua gives you good tools for all four.
