this post was submitted on 05 Aug 2026

50 points (94.6% liked)

Programming

28702 readers

346 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

The Lua community needs to learn to move on - hisham.hm (hisham.hm)

submitted 2 months ago by dhruv3006@lemmy.world to c/programming@programming.dev

17 comments fedilink hide all child comments

top 17 comments

sorted by: hot top controversial new old

[–] gravitas_deficiency@sh.itjust.works 13 points 2 months ago (3 children)

I know why we ended up where we are. I know the history because I was there: with the Lua/LuaJIT schism, people wanted to support both environments, and targeting 5.1 was a good way to support both. And then 5.2, 5.3, etc. came along and people wanted to keep supporting the latest PUC-Rio Lua, but still felt tied to the 5.1 anchor. I’m sure I’m partly to blame for this because I engaged in this and helped others, by maintaining compat-5.3, itself an evolution of compat-5.2, with a history tracing all the way back to compat-5.0, which predates my involvement with Lua… and then we’re talking over 20 years ago.

So I haven’t worked with Lua myself, but is that right? There are forward-incompatibilities in minor versions…? Because that honestly seems pretty fucking stupid. Making basically every version include breaking changes and refusing to follow semantic versioning standards that are designed to essentially account for that is pants-on-head stupid.

[–] azdle@news.idlestate.org 17 points 2 months ago (1 children)

refusing to follow semantic versioning standards that are designed to essentially account for that is pants-on-head stupid.

Seems like it would be a bit hard to follow a versioning scheme that it predates by almost 20 years. Lua 5.2 even predates semver 1.0.0.

Before semver there was basically no standardization in versioning schemes and the meaning that semver applied to version numbers basically didn't exist (at least in my experience) before it came around. Everyone just kinda had their own meaning for what version numbers meant.

[–] gravitas_deficiency@sh.itjust.works 6 points 2 months ago

Ok that’s actually an excellent point that I hadn’t accounted for lol

[–] trem@lemmy.blahaj.zone 13 points 2 months ago (2 children)

Python does it, too. ¯\_(ツ)_/¯

Makes it real fun when one of your dependencies requires, say, Python 3.12 and another breaks on 3.9+.

[–] FizzyOrange@programming.dev 5 points 2 months ago

Python is one of the worst offenders here. I don't think Python's poor behaviour should excuse Lua's.

But I can also see why Python is making breaking changes - a lot of Python is so bad it really makes sense to clean it up. I dunno if Lua is in that situation.

Anyway I think I would look to other languages like Go, Rust, Java, C++ which do a much better job. I don't think Go or Rust have any backwards incompatibilities (at least very very few) and C++ has a small number but they're for stuff that is truly ancient or almost completely unused. It's totally possible if you care about it.

[–] gravitas_deficiency@sh.itjust.works 3 points 2 months ago* (last edited 2 months ago)

Oh, most definitely.

Several months back I was kinda pulling my hair out over the frustrating state that Apache Airflow was in, because (due to my company’s infosec, SQA, and regulatory policies) I found some delightful mutually-exclusive transitive dependencies when I tried to diverge (with version upgrades to get past CVE-marked releases) the constraints from the officially-packaged constraints.txt. Though, that’s packages, not actual lang level.

Were you around for the 2 -> 3 migration? Now THAT was a categorical shitshow.

[–] kirisamemarisa@lemmy.eco.br 10 points 2 months ago (1 children)

from https://www.lua.org/versions.html:

The releases of Lua are numbered x.y.z, where x is the series, x.y is the version, and z is the release.

Different releases of the same version correspond to bug fixes. Different releases of the same version have the same reference manual, the same virtual machine, and are binary compatible (ABI compatible).

Different versions are really different. The API is likely to be a little different (but with compatibility switches), and there is no ABI compatibility: applications that embed Lua and C libraries for Lua must be recompiled. The virtual machine is also very likely to be different in a new version: Lua programs that have been precompiled for one version will not load in a different version.

[–] villainy@lemmy.world 10 points 2 months ago (1 children)

I like how there's no description of what a "series" is.

[–] AnyOldName3@lemmy.world 11 points 2 months ago

There doesn't really need to be as they've stuck to the same series for decades now.

[–] Zykino@programming.dev 9 points 2 months ago (1 children)

Are there migration path for projects embedding a LUA version? Or is LUA incompatible between version?

Like if I build a plugin for a project in LUA 5.1, and the project want to migrate to 5.5, are there forward incompatibilities? Are there API deprecated for long enough to let people migrate?

As an observer I don't understand why "once you choose a version for your project and a plugin ecosystem develop on it, you are married to this version".

[–] AnyOldName3@lemmy.world 12 points 2 months ago (2 children)

It's Lua, not LUA. It's Portuguese for moon, not an initialism.

You can't migrate once you've got a plugin ecosystem because you're not the maintainer of all third-party plugins, and the maintainers might have lost interest or died and used a licence that doesn't let anyone else take over.

[–] Zykino@programming.dev 3 points 2 months ago (1 children)

And in the mean time I read that there are frequent and apparently non trivial breakage on version.

Not trying to point finger since it is not easy, but thinking about the upgrade strategy of a project (or language) and help consumers of your project (and their plugin) get to the next version would help them on this issue. We have examples of languages doing this (or not). There may be more challenges for an embedded languages (than for Rust or Python) but I'm sure some concepts can still be applied anyway.

[–] AnyOldName3@lemmy.world 2 points 1 month ago

It's not really the intended use case of Lua to be used in things that will be upgraded after they're released. It's meant for things that need to work exactly the same way in a decade as they do now, and that's best served by sticking to a specific version and either only upgrading to bugfix releases, or sticking to one specific commit forever. Those use cases also are better served by sticking to old versions of any libraries they use that are written in Lua (otherwise they might be hit by regressions or turn out to have been reliant on old buggy behaviour that's been fixed), so probably aren't upgrading to newer versions. That's why the article is making the point that it's not worthwhile for the maintainers of those libraries to keep compatibility with old versions of Lua as the people still using old versions of Lua are probably going to be sticking to old versions of those libraries, too.

[–] bradboimler@lemmy.world 2 points 2 months ago (1 children)

It's Lua, not LUA. It's Portuguese for moon, not an initialism.

I wonder why people do this. Happens a lot with Java too.

[–] AnyOldName3@lemmy.world 2 points 2 months ago

I've not seen it so much with Java, but for Lua, it's not an English word, and most things in software are either English words or acronyms/initialisms, so it's usually a safe heuristic to assume anything that isn't an English word should be capitalised.

[–] arran4@aussie.zone 2 points 2 months ago

Won't work either a lot of distros mirror content to avoid things like this in the first place. But it does make things like forking harder.

[–] onlinepersona@programming.dev 1 points 1 month ago

I have long moved on from lua!