I'm building something like Lua for robots, you might want to check it out if you're looking to collaborate. I didn't know about Lua when I started it, but I did end up at an "everything is a table" metaphor because it seemed good for robotics. This does allow for cool things like hot reloading and such.

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.

> Balatro was one of the biggest games of last year, and I'm sure the tinkerability was a big catalyst to that

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.

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

Reminds me of WhatsApp that was on all devices early on to maximize their network effect.

With a little effort you can get mods working on Android. I have the cryptid mod installed on my phone.

> get it to run on SteamOS

Huh? I had to do zero extra work to run it on the steam deck.

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?

Do you have any reason to upgrade to 5.5?

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.

You're probably better off finding a way to support both.

You typically don't update Lua, you pick a version and stick with it.

Is transpilation a thing in the Lua world like it is for JavaScript?

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.

Most people don't use the standard library to make a HTTP request in Python either...

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.

You kind of always have to go on a quest for a library on the internet, why would lua be any different? For lua, luarocks is its module registry and you can sort by most downloads, which sometimes leads you to buggy modules, but what can you do.

That's not true, it was published in 2016. I just happen to know because I bought it last week to support the Lua Foundation in the wake of doing some work on Scribunto modules at the Wikimedia projects. They're using Lua 5.1.5, but I figured the author would indicate the feature introduction points and I was correct about that.

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.

Oh I hope that don't do that.

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.

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!

> 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

Kind of feels like they would pick python before lua.

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

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.

LuaJIT is its own thing though.

Anywhere where you run hot loops in Lua inside your own hot loop. Game engines and network appliances are the most common use cases.

The most recent integration I've seen is is OpenMW, which is an open source re-implementation of the Morrowind game engine. Basically it is built on the assumption that people are going to make mods that do a ridiculous amount of number-crunching in lua so any small improvement to performance is welcome.

If Python is your baseline, LuaJit is certainly going to be overkill. But to answer your question: when and where latency matters. Web apps, text editors, etc.

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.

If you ever want to look at example code, try going to rosettacode instead of the handpicked selection on the homepage of many websites.

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

But he has been working actively on LuaJIT. According to [1], he has come to the conclusion that, instead of working on LuaJIT 2.2, it would be a better investment of his time to go big on v3.0 and rearchitect it. LuaJIT 2.1 is to be maintained.

[1] https://www.freelists.org/post/luajit/Question-about-LuaJIT-...

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?