But.. why ? Globals are just variables that reside in the wrapping env table that also contain the C functions. If a closures is a onion of table lookups out of the function context from local -> function scope -> global scope is simply the last lookup before a not found variable with nil is declared?

The real reason everyone settled on Lua 5.1 is because that's the version LuaJIT is compatible with, and most people are unwilling to give up the performance gains.

5.1 (by way of LuaJIT) gets a lot of use, but to suggests no one uses the modern versions is just not true. Lua being an embedded language just takes the pressure away to upgrade. It's a feature, not a bug.

> everything seems to have settled on 5.1

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.

Only a dabbler in Love2d here but I’d expect that update to be a bit down the line. If I’m not mistaken the current Love2d version 11.5 is (mostly) tied to Lua 5.1 because of LuaJIT, though I understand some later Lua features are backported. And the changelog for the in-dev 12.0 release talks about compiling Love2d for Lua 5.4 as if it’s an optional thing.

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!

The Lua ecosystem is more like the Lisp ecosystem than Python. The language is small enough that there’s a lot of stuff out there that’s just… finished. Hasn’t been updated in 10 years but still works. The LunarModules org tries to gather it up and keep it compatible.

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.

Oh I hope that don't do that.

Mike Pall made a commit to LuaJIT just a couple of weeks ago.

Curious how this fits in with WASM

If they can lock it to some version to avoid breaking code every time there is a new Lua version. Or Lua stop making breaking changes.

Ypu could probably run it in wasm. Of course, without access to the DOM it won't go any further than anything else on wasm. The whole thing is nuts if you ask me. So much lost potential.

I think that's doable. https://github.com/zacharie410/lua-browser-dom-demo

> I feel like Lua is absolutely underrated.

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.

Because Lua's Hello World is just `print("hello, world")`, which looks a lot like Python and doesn't tell you much about actually using the language.

From the manual:

   The control variable in for loops is read only. If you need to change it, declare a local variable with the same name in the loop body.

Also [0]: Roberto Ierusalimschy > So what's the rationale to make them constant now? Does it have performance > reasons?

Yes. The old code does an implicit "local x = x" for all loops, in case you modify 'x'. With the new semantics, the code only does it when you ask for it.

[0] https://groups.google.com/g/lua-l/c/SlAG5QfpTac

In previous versions, you could change it mid-loop. This apparently caused some unintuitive behavior when paired with generators (e.g. `for k, v in pairs(table)`).

I haven't run into this myself, but it does make sense, and eliminating this footgun sounds like a good idea.

Yeah, I wish someone would pick up LuaJIT development. From what I've heard it's in practice isn't developed anymore and is stuck at Lua 5.1 still.