I miss working in Lua. Metatables are pretty powerful, and "everything is in a table" made it super easy to do hot reloading. At one point working on an iOS game, I had things set up so that when I hit save on my PC, my phone would pick up the changes and just start running the new code, as all persistent state was stored in a special table. Someday I need to look into getting the same kind of environment going for robotics, it was really a superpower.
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.
I think I could actually build what I was thinking of on top of basis, but need to think about some things. Serialization of internal state was kicked around as a design idea at the start, but didn’t see enough benefit back then. In any case basis isn’t quite dead, I still use the thing as a test bed for ideas.
I recently happened into Balatro through a Game Pass trial. I fell deep down the rabbit hole of trying to get it to run on SteamOS.
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, 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.
> 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.
The version sold in the Steam store runs the Windows build via Proton. (Valve's whole philosophy is you should build one version of your game, and their compatibility layers should be so bulletproof that it runs flawlessly everywhere.)
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.
One of the new features I found interesting, declarations for global variables, is buried in the reference manual. Here's a link to the section that discusses it: https://www.lua.org/manual/5.5/manual.html#2.2
Strictly speaking, Lua is not global by default. All free names, that is, all names unqualified with `local`, is actually indexed from a table `_ENV`, which is set to `_G`, the global environment. So, all free names are effectively global by default, but you can change this behavior by put this line at the top of your file `local _G = _G; _ENV = {};`. This way, all free names are indexed from this new table, and all access to the global names must explicitly be accessed through `_G`, which is a local variable now. However, I have never seen such practice. Maybe it is just too complicated to accept that all free names are global variables and you have to explicitly make it local.
Thanks to Lua’s great metaprogramming facilities, and the fact that _G is just a table, another workaround is to add a metamethod to _G that throws an error if you try to declare a global. That way you can still declare globals using rawset if you really want them, but it prevents you from declaring them accidentally in a function body.
yeah. I hate typing `local` for every variable. I would prefer they introduce some syntactic sugar like `let`(to mean local variable) and `const`(to mean local and constant).
For me it's interesting because global variable declarations haven't been needed before, so why now? Also, I'm not sure `global` was reserved before, but now it seems to be.
One challenge we have with Lua in Mudlet (FOSS text-based MUD client, think something akin to Roblox but for text) is that all of the player-created content is on Lua 5.1, and upgrading to 5.5 would be a breaking change for most.
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.
ConTeXt has been using beta versions Lua 5.5 for a few years now, so you can look through its source [0] or try running it [1] if you're curious what a large codebase written in Lua 5.5 looks like.
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.
Not true. It's getting a constant stream of bugfixes. It's also not "stuck" on Lua 5.1, but is deliberately not following Lua's path, except for some backports. There's also a recent post about how a LuaJIT 3 might work.
OK, then I got some wrong info. If it's stuck at it deliberately, then it's worse. May be someone should fork it and bring it up to date with recent Lua versions. Why is this split needed?
My understanding is that there was a language fork after 5.1. One thing was a complete reworking of how math works. It used to be just floating point for everything but the new idea was to make it like Python 3. So most operations are float/integer with some weird exceptions.
As with any language fork there will be some who stay and others who switch to the new thing. Often a fork will drive people away from a particular language as in my case.
Lua's nature as a primarily embedded language means backwards compatibility is not guaranteed between any version. If 5.2 was a language fork then so was 5.3, 5.4, 5.5, etc. (5.2 did have some more significant changes though)
For that reason luajit staying at ~5.1 actually works in its favor. Rather than trying to follow the moving target of the newest version, it gives a robust focal point for the lua ecosystem, while modern versions can be developed and continue to serve their purpose in embedded systems and whatnot where appropriate.
I don't see a reason not to update LuaJIT still. Changes in Lua aren't just version numbers, it should be improving something, meaning that would be missing in LuaJIT.
Isn't it a bit naive to declare that, just because Lua created a new minor version, it should be somehow better? The author of LuaJIT has often written his arguments, including why he disagrees with the changes to the language, why they should have been implemented as libraries instead, that in his view LuaJIT is still more performant and more widely used than PUC Lua, and more.
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.
LuaJIT does have some backported features from newer versions. But Mike Pall -- the mad genius behind LuaJIT -- has made it clear he doesn't agree with many of the changes made in newer versions, hence why it's staying where it's at.
In RHEL I would never touch system python at all, and would install what every version I needed in a venv and configure any software I installed to use what ever version I needed. I learned the hard way to never mess with system python.
The language is different. The changes to environments in particular are a non-starter. Sandboxing is incredibly clunky in 5.2+, and we lost a lot of metaprogramming power and dynamic behavior.
I strenuously disagree. Not every language needs to chase trends and pile on unnecessary complexity because developers want the latest shiny language toys to play with. It's good to have a simple, stable language that works and that you can depend on to remain sane for the forseeable future.
C is a language like that but I fear the feature creep is coming (auto? AUTO??.) JS is a lost cause.
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. I just wish one of the mainstream browsers actually puts their foot down and starts supporting Lua as scripting language.
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).
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.
That is correct. Not sure about all dialects of English but in American English, "nuts" is a slang synonym for "insane". So to say "the whole thing is nuts" could be rephrased as "the situation is crazy".
Seems like an odd change, I wonder what the rationale is. Just making it clear to people new to the language that you can't adjust it mid-loop to change the loop count I guess?
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.
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.
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.
For what kinds of applications is LuaJIT being used? I’ve always found the standard interpreter fast enough for my needs. Especially when compared to Python.
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.
I never coded in Lua but I found out recently that Lua is now in FreeBSD base [0]
This is huge for Lua and FreeBSD.
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.
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.
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.
There's nothing stopping anybody from making a batteries included lua, and plenty have done so (emilua, luapower, luaforwindows, luart and etc), of course, pure lua still exists and their changes are usually backported into lua since its so small and portable.
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.
Rather than Hello World, I'd rather see something like a classic Fibonacci calculator with recursion. That way you see function definitions, variable typing, math operations (Lua doesn't have increment/decrement operators or augmented assignments), and even tail-call recursion if it's an option. Hello World is really only useful as an environment verification - do you have your machine set up so you can run the code, or are you missing something?
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.
It makes sense when you look at how the numberic for loop looks in Lua.
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 think i might prefer indexing starting at zero, but it really isn't important. with c it makes total sense for zero-based indexing. frankly though, for lua, how it works and what an array is, it makes more sense for one-based indexing, the only counter-argument being that 1-based indexing puts off people who learned a thing one way and are unable or unwilling to do it a different way. to even include it on a list of considerations for not choosing lua is a bit silly, but to highlight array indexing and only that as the only thing you'd need to know... well i don't know how to put it that wouldn't be impolite.
either way, at least you can't toggle between indexes starting at zero and one, (at least not that i can recall.)
> either way, at least you can't toggle between indexes starting at zero and one
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.
iirc that value at key zero won't be included in any array handling functions. if that behavior were toggleable we'd have the kind of nonesense that early APLs allowed before they realized that's a bad thing to stuff in a global variable you can write to at any time in your program.
Cannot wait for another version of Lua to sit unused basically everywhere.
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)
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.
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
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.
Interesting, it looks like you can use ´global myvar’ now, as compared to ´myvar’ implicit globals, say from back in 5.1, or ´local myvar’.
It’s worth noting that global is a reserved keyword now, so environments that had a ´global()´ function for escaping environments will now need to rename their helper function.
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?
I miss working in Lua. Metatables are pretty powerful, and "everything is in a table" made it super easy to do hot reloading. At one point working on an iOS game, I had things set up so that when I hit save on my PC, my phone would pick up the changes and just start running the new code, as all persistent state was stored in a special table. Someday I need to look into getting the same kind of environment going for robotics, it was really a superpower.
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.
I think I could actually build what I was thinking of on top of basis, but need to think about some things. Serialization of internal state was kicked around as a design idea at the start, but didn’t see enough benefit back then. In any case basis isn’t quite dead, I still use the thing as a test bed for ideas.
I’ll take a look at your thing, too!
> I didn't know about Lua when I started it
How did you miss Lua? It has been available for decades and good SE practice is to evaluate alternatives before commiting to any techonology.
I recently happened into Balatro through a Game Pass trial. I fell deep down the rabbit hole of trying to get it to run on SteamOS.
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, 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.
> 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.
Yeah it is just a really easy to grasp game that pushes the right addiction buttons in our brain (see also the enormous success of megabonk)
Reminds me of WhatsApp that was on all devices early on to maximize their network effect.
I managed to run Balatro on a Trimui Brick on a very minimalist Linux distro, steamos should be easy.
It's now on Portmaster if anyone is curious -
https://portmaster.games/detail.html?name=balatro
That's rad!
Getting it to run in KDE was straightforward. I've gotta figure out why it instacrashes in SteamOS game mode.
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.
The version sold in the Steam store runs the Windows build via Proton. (Valve's whole philosophy is you should build one version of your game, and their compatibility layers should be so bulletproof that it runs flawlessly everywhere.)
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.
could it be that game mode is attempting to run the game in compat mode even though you are running the native build?
Interesting, great game I coincidentally also just started to play a few days ago
One of the new features I found interesting, declarations for global variables, is buried in the reference manual. Here's a link to the section that discusses it: https://www.lua.org/manual/5.5/manual.html#2.2
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.
Strictly speaking, Lua is not global by default. All free names, that is, all names unqualified with `local`, is actually indexed from a table `_ENV`, which is set to `_G`, the global environment. So, all free names are effectively global by default, but you can change this behavior by put this line at the top of your file `local _G = _G; _ENV = {};`. This way, all free names are indexed from this new table, and all access to the global names must explicitly be accessed through `_G`, which is a local variable now. However, I have never seen such practice. Maybe it is just too complicated to accept that all free names are global variables and you have to explicitly make it local.
Thanks to Lua’s great metaprogramming facilities, and the fact that _G is just a table, another workaround is to add a metamethod to _G that throws an error if you try to declare a global. That way you can still declare globals using rawset if you really want them, but it prevents you from declaring them accidentally in a function body.
yeah. I hate typing `local` for every variable. I would prefer they introduce some syntactic sugar like `let`(to mean local variable) and `const`(to mean local and constant).
“local” is the same as the “let” that you are describing, isn’t it? Just 2 chars longer.
Why did you find this interesting?
It indicates paving the path for local scoping in a future release where Lua 5 code is upgraded with global declarations to keep it working.
We have had local scoping for decades.
For me it's interesting because global variable declarations haven't been needed before, so why now? Also, I'm not sure `global` was reserved before, but now it seems to be.
lua does not preserve compatibility between minor versions. As such they don't need to reserve words for future use.
One challenge we have with Lua in Mudlet (FOSS text-based MUD client, think something akin to Roblox but for text) is that all of the player-created content is on Lua 5.1, and upgrading to 5.5 would be a breaking change for most.
Has anyone solved an ecosystem upgrade like this?
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?
Like https://moonscript.org/ or https://teal-language.org/ ?
ConTeXt has been using beta versions Lua 5.5 for a few years now, so you can look through its source [0] or try running it [1] if you're curious what a large codebase written in Lua 5.5 looks like.
[0]: https://codeberg.org/contextgarden/context
[1]: https://wiki.contextgarden.net/Introduction/Installation
We never got a new edition of Programming in Lua for 5.4... does that mean we won't ever get one for 5.5?
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.
According to https://www.lua.org/pil/
> Fourth edition
> Programming in Lua
> by Roberto Ierusalimschy
> Lua.org, August 2016
> The fourth edition updates the book to Lua 5.3
Oh I hope that don't do that.
> declarations for global variables
That's huge. I wish LuaJIT adopted this, or at least added a compile time flag to enable it.
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.
Not true. It's getting a constant stream of bugfixes. It's also not "stuck" on Lua 5.1, but is deliberately not following Lua's path, except for some backports. There's also a recent post about how a LuaJIT 3 might work.
Where is that post?
https://www.freelists.org/post/luajit/Question-about-LuaJIT-...
Warning: Ridiculous cookie consent banner, needs dozens of clicks to opt out.
This cookie consent banner is handled in 0 clicks thanks to Consent-O-Matic Firefox extension
OK, then I got some wrong info. If it's stuck at it deliberately, then it's worse. May be someone should fork it and bring it up to date with recent Lua versions. Why is this split needed?
My understanding is that there was a language fork after 5.1. One thing was a complete reworking of how math works. It used to be just floating point for everything but the new idea was to make it like Python 3. So most operations are float/integer with some weird exceptions.
As with any language fork there will be some who stay and others who switch to the new thing. Often a fork will drive people away from a particular language as in my case.
Lua's nature as a primarily embedded language means backwards compatibility is not guaranteed between any version. If 5.2 was a language fork then so was 5.3, 5.4, 5.5, etc. (5.2 did have some more significant changes though)
For that reason luajit staying at ~5.1 actually works in its favor. Rather than trying to follow the moving target of the newest version, it gives a robust focal point for the lua ecosystem, while modern versions can be developed and continue to serve their purpose in embedded systems and whatnot where appropriate.
I don't see a reason not to update LuaJIT still. Changes in Lua aren't just version numbers, it should be improving something, meaning that would be missing in LuaJIT.
Isn't it a bit naive to declare that, just because Lua created a new minor version, it should be somehow better? The author of LuaJIT has often written his arguments, including why he disagrees with the changes to the language, why they should have been implemented as libraries instead, that in his view LuaJIT is still more performant and more widely used than PUC Lua, and more.
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.
LuaJIT does have some backported features from newer versions. But Mike Pall -- the mad genius behind LuaJIT -- has made it clear he doesn't agree with many of the changes made in newer versions, hence why it's staying where it's at.
the beauty of open source is there's nothing stopping you! this might be your calling. best of luck
Language fork is unfortunate. Python situation isn't much of a fork really. Python 2 is basically EOL.
There’s no “basically”. Stick a fork in it; it’s done: https://www.python.org/doc/sunset-python-2/
It might not be supported by the consortium, but python2 still lives, slowly, in one place or another:
> The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's Python 2.7 package at June 2024.
https://access.redhat.com/solutions/4455511
At this point in RHEL it is only "deprecated", not "obsolete".
In RHEL I would never touch system python at all, and would install what every version I needed in a venv and configure any software I installed to use what ever version I needed. I learned the hard way to never mess with system python.
Which is better than this mess with Lua situation.
The language is different. The changes to environments in particular are a non-starter. Sandboxing is incredibly clunky in 5.2+, and we lost a lot of metaprogramming power and dynamic behavior.
> May be someone should fork it and bring it up to date with recent Lua versions. Why is this split needed?
Good news, you're someone. If you care, you're welcome to go for it.
I strenuously disagree. Not every language needs to chase trends and pile on unnecessary complexity because developers want the latest shiny language toys to play with. It's good to have a simple, stable language that works and that you can depend on to remain sane for the forseeable future.
C is a language like that but I fear the feature creep is coming (auto? AUTO??.) JS is a lost cause.
Excellent new release, now for Fennel and Love2d to update, fun times!
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!
It's best to say that its tied to luajit, because at this rate, luajit is its own mixture of lua features, which they backport from newer versions.
List of changes: https://lua.org/manual/5.5/readme.html#changes
I feel like Lua is absolutely underrated. I just wish one of the mainstream browsers actually puts their foot down and starts supporting Lua as scripting language.
> 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.
That was originally what Dart was created for.
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).
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 transpiled the runtime into wasm and made an interactive shell: https://thecatbutt.com/lua/
What is nuts?
It's slang, it's a reference to legumes I think. https://en.wikipedia.org/wiki/Legume
lost potential of wasm not being allowed access to dom
Means like "a crazy thing" in slang, I think.
That is correct. Not sure about all dialects of English but in American English, "nuts" is a slang synonym for "insane". So to say "the whole thing is nuts" could be rephrased as "the situation is crazy".
I think that's doable. https://github.com/zacharie410/lua-browser-dom-demo
(Using https://github.com/fengari-lua/fengari-web )
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
> for-loop variables are read only
Seems like an odd change, I wonder what the rationale is. Just making it clear to people new to the language that you can't adjust it mid-loop to change the loop count I guess?
From the manual:
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
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.
For what kinds of applications is LuaJIT being used? I’ve always found the standard interpreter fast enough for my needs. Especially when compared to Python.
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.
Anywhere where you run hot loops in Lua inside your own hot loop. Game engines and network appliances are the most common use cases.
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.
I never coded in Lua but I found out recently that Lua is now in FreeBSD base [0] This is huge for Lua and FreeBSD.
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...
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.
> You kind of always have to go on a quest for a library on the internet
Plenty of languages come with standard libraries that are more than sufficient for handling plenty of tasks.
There's nothing stopping anybody from making a batteries included lua, and plenty have done so (emilua, luapower, luaforwindows, luart and etc), of course, pure lua still exists and their changes are usually backported into lua since its so small and portable.
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.
How hard is it to put a simple hello world example on the homepage.
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.
The point is, it shouldn’t be too hard just to find an example and get a sense of the language.
Learn x in y is always my goto: https://learnxinyminutes.com/lua/
So put a slightly more informative hello world example then.
Look at the Go homepage. Or Nim. (But not Rust sadly.)
Rather than Hello World, I'd rather see something like a classic Fibonacci calculator with recursion. That way you see function definitions, variable typing, math operations (Lua doesn't have increment/decrement operators or augmented assignments), and even tail-call recursion if it's an option. Hello World is really only useful as an environment verification - do you have your machine set up so you can run the code, or are you missing something?
Look at the Go homepage. It has a variety of examples.
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.
It makes sense when you look at how the numberic for loop looks in Lua.
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 think i might prefer indexing starting at zero, but it really isn't important. with c it makes total sense for zero-based indexing. frankly though, for lua, how it works and what an array is, it makes more sense for one-based indexing, the only counter-argument being that 1-based indexing puts off people who learned a thing one way and are unable or unwilling to do it a different way. to even include it on a list of considerations for not choosing lua is a bit silly, but to highlight array indexing and only that as the only thing you'd need to know... well i don't know how to put it that wouldn't be impolite.
either way, at least you can't toggle between indexes starting at zero and one, (at least not that i can recall.)
> either way, at least you can't toggle between indexes starting at zero and one
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.
iirc that value at key zero won't be included in any array handling functions. if that behavior were toggleable we'd have the kind of nonesense that early APLs allowed before they realized that's a bad thing to stuff in a global variable you can write to at any time in your program.
I don’t see a problem. That’s how people count.
If you ever want to look at example code, try going to rosettacode instead of the handpicked selection on the homepage of many websites.
Cannot wait for another version of Lua to sit unused basically everywhere.
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)
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.
And Luau.
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.
True. But
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 pretty sure that's only OpenResty's distribution of LuaJIT.
I think the real LuaJIT is strictly 5.1
Not true, see "Extensions from Lua 5.2" here: https://luajit.org/extensions.html
No, real LuaJIT has some features from 5.2 and 5.3
https://luajit.org/extensions.html
OG torch strikes back?
Still waiting[0][1] for proper RISC-V support.
0. https://github.com/LuaJIT/LuaJIT/issues/628
1. https://github.com/LuaJIT/LuaJIT/pull/1267
LuaJIT is its own thing though.
You're right.
Still, hard to do w/o.
What is still hard to do without?
please resurrect Mike Pall
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-...
Mike Pall made a commit to LuaJIT just a couple of weeks ago.
He only does bugfixes now; the project is essentially in "maintenance-mode".
Interesting, it looks like you can use ´global myvar’ now, as compared to ´myvar’ implicit globals, say from back in 5.1, or ´local myvar’.
It’s worth noting that global is a reserved keyword now, so environments that had a ´global()´ function for escaping environments will now need to rename their helper function.
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?
Module exports with side effects, and setting environments doesn’t guarantee global access.
[dead]
[flagged]