This is exactly right. From "Challenges with Python " in TFA:
> I ended up introducing incompatibilities with older versions of Python when I tried using a finally block with an exception block—that syntax was not available until version 2.6
Lua changes major parts of the language in minor revisions. 5.1, 5.2, and 5.3 are not compatible, and in much larger ways than Python 2.6 and 2.7. Lua 5.1 is currently the most recent version supported by LuaJIT which he specifically mentions. Lua 5.3 introduces integers!
> For example, I needed to add support for detecting the Ethernet addresses of the host computer, which can be done with the netifaces native library (or shell out to ifconfig and parse the results, which would not be compatible with Windows).
You're going to have exactly the same problem with Lua, except that that library won't exist so you'll have to write it.
Lua's great, but this isn't a case of Lua being better than Python for your use case. It's a case of you redoing your deployment in such a way that you happen to have more control.
Lua is famous for breaking compatibility between versions. And Lua users are quite aware of the situation. But outsiders tend to overblow the situation, making more noise than the people actually having to deal with it.
The Lua creators are very careful and deliberate in how they break compatibility.
One such thing they do is they avoid subtle changes that can lead to incorrect/different results, and prefer hard things that lead to obvious compile time errors.
But most of the time, the changes between minor revisions aren't a big deal. On the Lua side, authors have been pretty good about figuring out how to make their scripts run across all versions because the changes haven't been that big. On the C side, the API changes can be a little more dramatic, but authors have been good about handling the differences.
Most are stuck with Lua 5.1 anyway as it's the version supported by LuaJIT2. But 5.1 is very good. And the Lua community is very loosely connected and quite different due Lua's embedded nature.
I made much Lua code, and one thing that makes a major difference, is that Lua devs frequently discuss what they are planning to break.
For example I wrote many games in Lua 5.1, that actually work in Lua 5 if I wanted to, and also work in Lua 5.2, despite 5.2 not existing when I wrote them.
I don't checked yet the changes on 5.3, but I suspect my games might work on 5.3 without changes too.
You pretty much always ship Lua embedded in your application though, as it is just a C library. It is the expected use case, rather than using a system copy.
> I ended up introducing incompatibilities with older versions of Python when I tried using a finally block with an exception block—that syntax was not available until version 2.6
Lua changes major parts of the language in minor revisions. 5.1, 5.2, and 5.3 are not compatible, and in much larger ways than Python 2.6 and 2.7. Lua 5.1 is currently the most recent version supported by LuaJIT which he specifically mentions. Lua 5.3 introduces integers!
> For example, I needed to add support for detecting the Ethernet addresses of the host computer, which can be done with the netifaces native library (or shell out to ifconfig and parse the results, which would not be compatible with Windows).
You're going to have exactly the same problem with Lua, except that that library won't exist so you'll have to write it.
Lua's great, but this isn't a case of Lua being better than Python for your use case. It's a case of you redoing your deployment in such a way that you happen to have more control.