Re: The Future of Lua's C ABI Compatibility

[Paul Ducklin <pducklin@...>]

>the embedded purpose of Lua means 
>once a codebase implements a version, 
>it's likely never going to update..

If a software project isn’t going to update anything, doesn’t that neatly solve your problem of having to recompile when anything changes? No updates means no changes means no rebuilds.

As for needing to recompile your project when a new version comes out so that the modules and the runtime match up…

…that’s how the Linux kernel has always worked (modules must be recompiled against the headers of the current kernel, even if only the rightmost version number changes). Even if you find it annoying it doesn’t seem to have harmed the adoption of Linux against, say, the BSDs, and it is easily automated.

I use Lua as a day-to-day scripting and prototyping language and my preference is static linking, so I have no choice but to recompile and rebuild my single binary every time either Lua itself, or one of my chosen Lua C extensions, or one of my pure-Lua modules, or one of the third-party libraries they need (e.g. OpenSSL, needed by LuaOSSL and LuaSec) changes.

I consider that a strength (I can state exactly which versions of every embedded C or Lua module will be used when you run a specific Lua binary of mine, and I run by default with no Lua or C path set so that nothing works “by mistake”). It also reminds/forces me to re-run all my standard module tests every time anything changes, and stops me falling back on the NPM-like approach of LuaRocks, where things update to suit other people’s workflows and agendas.

If Lua has a module compatibility problem, I suggest it is simply that there are lots of old, unmaintained and frankly unusable projects out there that haven’t been updated for years (or that diverged from Lua many years ago by taking the incompatible LuaJIT fork, but don’t realise or won’t acknowledge that they are not *Lua* modules at all any more), which can indeed be confusing or disappointing when shopping for code for your project.

There isn’t a sizeable, strongly curated core of “standard” Lua modules maintained by the Lua team itself, as there is in, say, Python.

But Lua is not Python and “being another Python” is not part of the vision or desire of the Lua team. (For me, it means I feel I “understand” the Lua ecosystem to a degree that I just don’t feel I could ever grok Node.is or Python.)

I don’t see the “need to recompile” as onerous at all, any more than I do waiting the few seconds for my non-standard Linux modules to rebuild after each kernel update. (And I use Slackware-current, which typically gets every new kernel version within 24 hours of release :-)