Blog — clx

The Trials and Tribulations of Native Lua Compilation October 2026·12 min read I have been working with Lua for a long time, and one of the things I have always liked about the language is how little it needs. It is small, elegant, portable, and remarkably easy to embed. That last property is probably one of the reasons Lua has been so successful: you can put a Lua interpreter inside a game, an application, a tool, or almost anything else and immediately gain a powerful scripting language. But after using Lua for years, I eventually started running into the other side of that design. Whenever I wanted to build and distribute a Lua application, there was always a Lua VM somewhere in the picture. With LuaRT and its rtc compiler, I had already solved a large part of the deployment problem, at least on Windows. I could package a Lua application as a standalone executable instead of asking users to install Lua separately. That worked well, but it left me with another question. Even if the interpreter was embedded in the executable, the application was still ultimately running Lua code through a Lua VM. The executable might look like a native application from the outside, but underneath it was still a Lua program being interpreted. I wanted to see what would happen if I went one step further. I wanted a genuinely native Lua experience, without depending on lua55.dll, liblua55.so, or an embedded Lua VM to execute the application. I wasn't trying to eliminate the runtime entirely — a compiled Lua program still needs native support for things like tables, strings, garbage collection, coroutines and the rest of the Lua semantics. What I wanted was to replace the general-purpose Lua VM with a runtime designed specifically to support compiled native Lua code. If I could also get some additional performance out of the process, that would be a nice bonus.

That idea eventually became clx.

Packaging a VM vs compiling a program The important difference between rtc and clx is the way they approach the problem. A system based around the Lua VM can package an application very conveniently. The Lua source or bytecode is bundled together with the interpreter, and the interpreter takes care of executing it. From a deployment perspective, that can be perfectly reasonable.

clx takes a different approach.