Languages, Versions and Lua 5.2

As a user of Lua 5.2, I sometimes get frustrated about how little support the Lua libraries and tools people have given version 5.2.

Other languages

However, I guess Lua isn’t the only one suffering: I’m still using Python 2.7 rather than Python 3, simply because it’s easier than taking time out to port my applications or have to deal with two versions of the language (I have the feeling it’s slightly more complex because I have plenty of strings-being-used-as-byte-arrays in a bunch of my Python projects).

And look at the adoption of the new C and C++ standards, which took years and isn’t complete. It felt like over a decade before C99 was a standard fully-supported option in a lot of computers ... by which time I was using (sometimes a subset of) C++ anyway. And C89 took years after K&R C.

C++98 was poorly supported for years by commercial vendors; embedded tool vendors even branched the language (EC++) rather than support it. And the C++11 standard (which has some great features) will take a while for commercial vendors to catch up. Still, everyone is using GCC or LLVM aren’t they ;-) (which are much closer to C++11 compliance).

Back to Lua

Lua 5.2 was released 16 Dec 2011. It was relatively recently (June 11th, 2013) when the cool Eclipse LDT was updated to support 5.2. The Zero Brain Studio author is still figuring out how to support 5.1, 5.2 and LuaJIT easily. (To be fair: It’s fully possible in most of the IDEs to remotely debug any Lua runtime - especially important as Lua is embedded within programs very often, and ZBS can be switched to work Lua 5.2).

Why do I choose Lua5.2 in the first place?

1. Bit32 lib is standard, and I’m using it on embedded hardware running Lua and on a Lua emulator project I’m working on. No extra libraries required. Also the GC looks like it has fixes that are good.
2. Starting new projects on 5.1 seems insane long term (even though I’ve was advised otherwise).

What factors affect adoption?

• Lua applications developers don’t like moving up because it costs them work for little perceived return.
• Libraries are not available for the new version - critical in Lua’s case because the core language only supports an OS interface based on basic C. Projects like LuaSocket are critical to remote debugging - and although the repository has had Lua 5.2 compatibility for a while, there isn’t a released version (as far as I can tell) and requires people to build from source.
• Library and IDE developers mostly work on other things for work, and this is either a support task at work or a hobby project. So things take a while, and often depend on other components and their current projects.
• For Lua the LuaJIT project is very important to the eco-system. The author has stated he doesn’t like a few of the Lua 5.2 features, and additionally only has limited time to work on LuaJIT. He also has to maintain the Lua 5.1 compatibility in LuaJIT because several applications using Lua 5.1 code depend on it.
• Some Lua users can’t switch are dependant upon a runtime inside an application or framework - so have no choice to move. A specific case here are the game frameworks like Löve 2D, Gideros, Moai, Corona, etc. (And there is some pressure against moving versions in frameworks by users, who would end up with work to do to port their projects.)

What are the risks?

The lack of full support for Lua 5.2 is fragmenting the user-base and making the language a less popular choice when people come to evaluating the language.

Python is *just* about big enough to support two major versions. Lua isn’t. And it almost stopped me using it. Who wants to use a language where all the major libraries and tools are stuck in history land? Which would have been a pity because it’s a great language.