Lua 5.5
Key topics
The release of Lua 5.5 has sparked a lively debate about the adoption of Lua versions, with some commenters lamenting that Lua 5.1 remains the de facto standard due to its compatibility with LuaJIT. However, others counter that LuaJIT has actually incorporated features from later versions, making it more versatile than its 5.1 roots. As the discussion unfolds, it becomes clear that Lua's embedded nature reduces the pressure to upgrade, and that modern versions are indeed being used, even if not as widely as 5.1. The conversation also highlights the complexities of LuaJIT's feature set and the need for better documentation.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
101
Day 2
Avg / period
21.8
Based on 131 loaded comments
Key moments
- 01Story posted
Dec 22, 2025 at 10:06 AM EST
13 days ago
Step 01 - 02First comment
Dec 22, 2025 at 11:31 AM EST
1h after posting
Step 02 - 03Peak activity
101 comments in Day 2
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 2, 2026 at 2:22 PM EST
1d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Truly is a shame, everything seems to have settled on 5.1 for the most part without ever being updated, or any intention of it being updated. Some really nice features post 5.1
I understand each version of Lua introduces breaking changes in the language, which isn't great as the language becomes fragmented (Or not really, once again 5.1 is pretty ubiquitous)
Not exactly. LuaJIT has backported various hot features from 5.2 and 5.3 as long as they're unlikely to break 5.1 code.
I think the real LuaJIT is strictly 5.1
1. The luajit documentation basically just had a list of features. AFAIK there isn't any documentation that combines the 5.1 reference with luajit extensions (including things that were backported)
2. In some cases, for example Neovim, luajit extensions aren't guaranteed to be available. It just says there will be a lua runtime compatible with 5.1. Which means a truly portable neovim plugin can't use those extensions
3. There are features from later lua versions I would like to have (in particular <const> and <close>) that will probably never get backported.
4. Some features require luajit to be built with special flags
I'm a little sad they go the way similar to Python at the first glance. For me the way TypeScipt took initially and ECMAScript picked up eventially, with explicit export but lexical scoping otherwise, seems like the best "don't make me think" way. Why I should care about global/local inside a module? What benefits does it give vs lexical scoping with shaddowing allowed?
I don’t really follow LuaJIT too closely so I’m not sure if they’re even targeting Lua 5.4 let alone 5.5. I remember reading some GitHub issue that suggested some of the design decisions in Lua 5.4 wouldn’t really support LuaJIT goals re: performance.
With that said I’ve been enjoying Love2d even with Lua 5.1 features — as a hobbyist it works just fine for me.
Would certainly appreciate any corrections by those more in-the-know though!
Now something that worry me is whenever you need to make an HTTP request or parse some JSON you need to go on a quest for a "library" on the Internet. It doesn't seems to have a (semi-)official "Extended Standard Library" I can quickly trust.
- [0] https://man.freebsd.org/cgi/man.cgi?query=flua&apropos=0&sek...
Plenty of languages come with standard libraries that are more than sufficient for handling plenty of tasks.
FWIW you can do a lot with pure lua and unless you're importing json there's no reason to include a library for it given that lua itself can be used as the data exchange format.
For an extended standard lib, the closest thing is probably Penlight. https://github.com/lunarmodules/Penlight If you want async IO, sockets, etc, check out Luvit. https://luvit.io
Lua is really designed as an extension language but it’s such a nifty little language that sometimes you really wish you could use it in place of Python or Perl, which is why LuaJIT is so popular. But LuaJIT is really just one guy’s project. Its metaprogramming features are really nice and let you build some Lisp-style DSLs, and if you want full Lisp syntax you can drop in Fennel. If you’re just writing extension code you often don’t need a standard lib because it’s easier just to roll your own function to fill the gap.
Personally, I found it easier and quicker to just read the reference manual to learn the language. It’s small and simple enough that you shouldn’t have trouble getting up to speed if you have a couple other imperative languages under your belt. IMO metatables are much easier to work with than JavaScript’s prototype inheritance.
I agree with the sentiment though, I even gave a talk about this at Lua Workshop 2013 (https://www.lua.org/wshop13/Chapuis.pdf) around that issue. There are good reasons why several important but OS-specific features are not included in the core language. Discussion around a "blessed" extended standard library module arise from time to time but never lead anywhere.
The Lua community - at least the one around PUC Lua - is reasonably small and you can typically look at what active popular projects use to figure out the best libraries. The LuaRocks download count can be an indicator as well. But I agree this is still a problem.
I'm only just over halfway through but if I'm being honest, I can't offer much praise for the depth of the material or the treatment it's given: other authoritative volumes I've previously consulted (strangely, Mastering CMake comes to mind first among that cohort) were much more effective at communicating the underlying philosophies of construction and other unobvious practical realities of their subjects. Nevertheless, I do still value having a comprehensive reference at hand to refresh my memory on what's in fact possible when working with a language that I make use of as infrequently as this one.
> Fourth edition
> Programming in Lua
> by Roberto Ierusalimschy
> Lua.org, August 2016
> The fourth edition updates the book to Lua 5.3
[1] https://www.freelists.org/post/luajit/Question-about-LuaJIT-...
This sounds like an offhand Youtube comment, I'm afraid. Underrated how? Its principal strength, easy embedding with the ability to work as an extension language, is well known in the circles where it matters. The authors never gave an impression that they'd aim to make it a language to bury all other scripting languages, which I find refreshing in the winner-take-all culture of programming language discussion. Lua is modest and works well for what it is. No need to go all grandiose.
> I just wish one of the mainstream browsers actually puts their foot down and starts supporting Lua as scripting language.
I sincerely hope not, that would be a very counterproductive dilution of effort. Browser authors already have their plate full with all other web platform problems.
Beside all the rabblerousing that it came from the same company as Chrome, there was a real concern about compatibility and spreading the platform too thin, if every engine had to maintain multiple VMs in parallel.
It seems like the only language browsers will ever have is JavaScript (although it's still up to us to decide how that language evolves over time).
That's directly contrary to what would make it acceptable as a web spec, compared to e.g. wasm being powerful enough to be a compile target that can support wasm.
Look at the Go homepage. Or Nim. (But not Rust sadly.)
either way, at least you can't toggle between indexes starting at zero and one, (at least not that i can recall.)
You can, you just have to explicitly assign something to a[0]. Lua doesn't have real arrays, just tables. You have to do it for every table you use/define though, so if you mean "toggle" as in change the default behavior everywhere then I believe you are correct.
In Lua you specify the “beginning” and “end” of the iteration, both included. It doesn’t work like in C, where you have an initialization and an invariant. What makes it short in C would make it longer in Lua, and viceversa.
You could argue “why not make loops like C”, then. But that can be extended to the limit: “why have a different language at all?”.
I haven't run into this myself, but it does make sense, and eliminating this footgun sounds like a good idea.
That's huge. I wish LuaJIT adopted this, or at least added a compile time flag to enable it.
As with any language fork there will be some who stay and others who switch to the new thing.
As for forking, you can try, but I would warn you that one does not simply fork LuaJIT. Required is deep expertise in tracing JIT compilers, in assembly and in many different computer architectures. Nobody was really up to the task when Mike Pall announced that he was searching for a maintainer, before his eventual return.
C is a language like that but I fear the feature creep is coming (auto? AUTO??.) JS is a lost cause.
Good news, you're someone. If you care, you're welcome to go for it.
LuaJIT implements a fair amount of 5.2 and even has an optional compatibility toggled. Nobody really cares to do anything else.
Warning: Ridiculous cookie consent banner, needs dozens of clicks to opt out.
It's fascinating to see a commercial game whose source is easily read inside the application bundle, and all the modding opportunities it opens up. (It's written in Lua with LÖVE.) Balatro was one of the biggest games of last year, and I'm sure the tinkerability was a big catalyst to that - people porting it to obscure platforms and making mods to extend the game.
It's also really cool to see how the game handles all the different ecosystems it exists in (Steam, Game Pass, Apple App Store, Android, Nintendo Switch…).
I've got a Nix derivation that ought to be able to run any version of the game in Linux. Now I just need to figure out why it crashes when opened in game mode.
All this is way more effort than just spending the $10 to get it to run in Steam natively, but it's more interesting this way.
Getting it to run in KDE was straightforward. I've gotta figure out why it instacrashes in SteamOS game mode.
https://portmaster.games/detail.html?name=balatro
Huh? I had to do zero extra work to run it on the steam deck.
In this case, I had the Game Pass version. It depends on a custom shared object `love.platform` that talks to Microsoft's cloud APIs to save/load your game and achievements. I used Gemini to write a bridge that implements all the `love.platform` calls in pure Lua, and then use the Linux build of LÖVE to run the game natively.
Works great in KDE. Crashes when launched from Steam. Haven't gotten to why yet.
Not sure I agree on that point. Balatro is a great game and the mainstream success is warranted, but my gut tells me that the technical implementation was not the catalyst for that. Sure, Lua’s portability could have led to the cross-platform popularity, but a mainstream gamer does not tinker with and mod Balatro at all.
Has anyone solved an ecosystem upgrade like this?
Many people still use 5.1 because that is already a complete language that works fine. Most people don't really need the new features. Plus if you stay on 5.1 you get compatibility with LuaJit and Luau so much better performance.
Although, we've since moved to having several distinct data structures which conceptually map to tables, but implementation and syntax-wise have differences (mostly for performance).
BTW Basis was a good idea, I remember reading about Nondeterministic replay is a big problem on platforms like ROS.
I’ll take a look at your thing, too!
How did you miss Lua? It has been available for decades and good SE practice is to evaluate alternatives before commiting to any techonology.
0. https://github.com/LuaJIT/LuaJIT/issues/628
1. https://github.com/LuaJIT/LuaJIT/pull/1267
Still, hard to do w/o.
[0]: https://codeberg.org/contextgarden/context
[1]: https://wiki.contextgarden.net/Introduction/Installation