I managed to run Balatro on a Trimui Brick on a very minimalist Linux distro, steamos should be easy.

Global-by-default scoping was one of Lua's largest mistakes. I wish they'd fix it, but of course it would break backwards compat.

Why did you find this interesting?

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

Oh I hope that don't do that.

> 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.

One of the super powers of Lua is that it doesn't need to be very stable: because you are always embedding an interpreter your code and interpreter have a matching version.

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.

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

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.

Curious how this fits in with WASM

Kind of feels like they would pick python before lua.

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!

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.

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

That was already the case in previous versions of Lua. You could assign to the loop variable but the assignment would be overwritten in the next loop iteration.

https://www.lua.org/manual/5.3/manual.html#3.3.5

The loop count was fixed at the start of the loop. One of the reasons for this was performance. For loops behave differently if the step count is positive or negative, and it's a bit faster to compute that once, before the loop, than to repeat it every iteration.

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.

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.

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.

Well. You’d have to demonstrate that a[1] is the first offset in an array, and it’s not a great curb appeal to anyone who has programmed computers before.

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.

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?

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