The evolution of Lua, continued

[Luiz Henrique de Figueiredo]

The paper "The evolution of Lua, continued" has just appeared in
Journal of Computer Languages:
https://www.lua.org/doc/cola.pdf
https://doi.org/10.1016/j.cola.2025.101326

It is a continuation of the HOPL III paper:
https://www.lua.org/doc/hopl.pdf

From the Acknowledgments in the new paper:
We are very grateful to all Lua users and all companies that have
adopted Lua for their products: They are a continuous motivation for
improving Lua. Special thanks go to the members of our mailing list,
for their ideas and suggestions, which are generously shared in a
friendly environment. We thank the guest editors Francisco Sant’Anna
and Sérgio Medeiros for organizing this special issue to celebrate 30
years of Lua.

--lhf

[Pierpaolo Bernardi]

Thank you Luiz, and all the Lua team!

Is there a freely viewable copy of the paper available?

> --
> You received this message because you are subscribed to the Google Groups "lua-l" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/lua-l/CAD55k3qa9RK0kE7_ydR8T_ZjUqkorKMU%2BMfLX8vGERuMVDVKWQ%40mail.gmail.com.

[Pierpaolo Bernardi]

Please disregard

I had missed onr of the lnks... :)

[blog...@gmail.com]

Thanks :)

воскресенье, 27 апреля 2025 г. в 15:31:38 UTC+3, Pierpaolo Bernardi:

[The Future of Programming]

Hello Luiz

Thank you very much for sharing the article, I enjoyed reading it, it comes with very useful information about Lua and I like the discussion about integers support and the improvements done to the garbage collector.

Just a few comments

1. While the article provides a graph about each version and period of time, such a graph could be extended with supported features and implementation size (LOC). 

2. The introduction of generational collector (based on the idea that most objects die young) is very good, however, this still requires processing/attention from the GC. Another idea is to simulate the concept of stack when allocating objects, where these objects die after the end of the scope (without the need for reference counting) - This provides Realtime/predictable performance. In reality we applied such an idea in the Ring language where using references is optional, and allocations are scope based. It was very complex to add references to the implementation after everything was designed to be scope based and avoid references. But in Lua, going the other way around (supporting scope-based allocations without references) could be added using specific/new syntax. This way the programmer could write code that avoid GC overhead. I am just sharing this idea, maybe someone could find it interesting and try to do some experiments.

Finally, Thanks again for such a beautiful article and great language, Lua is the language that helped me to understand how having a lightweight implementation is very important. for example, using the same Lua implementation we can create software for Desktop/Microcontrollers, while in other languages another implementation is required (Python/MicroPython), (Ruby/mRuby), etc.

Greetings,

Mahmoud

[Andrew Starks]

Thank you for publishing this and for the excellent read.

I’ve been a passionate fan of Lua since I first became obsessed with it when 5.1 was brand new. It brings me real joy to see Lua’s history recorded so thoughtfully.

While Lua is extremely popular in some circles, it remains underappreciated by much of the broader programming world. Simplicity takes time to be fully understood. I believe that, in time, Lua will be recognized as one of the most beautiful programming languages — and one of the most elegantly implemented — in history.

-- Andrew Starks

[云风 Cloud Wu]

Very awesome article, I enjoyed reading it :)

For the luajit part :

> In particular, LuaJIT refused to implement the new lexical scheme for globals described in §3.2, thus breaking the compatibility with future versions of Lua.

It seems that adding _ENV support to luaJIT is not difficult，because
it is just a syntactic sugar in my opinion.
I made a very small patch for luajit in 2012 (
https://blog.codingnow.com/2012/10/luajit_20_lua_52_env.html )

But I quickly gave up using luajit because luajit does not bring the
expected performance improvement (10~15% only) , much less than the
benefits of using multi-lua states in multi-threaded environments.
And each luajit state costs more memory than lua. In earlier luajit
versions, multiple luajit state shared a total of 2G memory space. For
my project, this memory limit is the worst problem.

--
http://blog.codingnow.com

[Sainan]

> because luajit does not bring the expected performance improvement (10~15% only)

That is kinda funny, but it did always feel to me like the 'affection' for LuaJIT was more because of it being a 'shiny thing' rather than based on practical consideration.

Just a shame that it still ended up doing a lot of harm for the adoption of Lua 5.3 and above.

-- Sainan

[云风 Cloud Wu]

'Sainan' via lua-l <lu...@googlegroups.com> 于2025年4月30日周三 12:24写道：

>
> > because luajit does not bring the expected performance improvement (10~15% only)
>
> That is kinda funny, but it did always feel to me like the 'affection' for LuaJIT was more because of it being a 'shiny thing' rather than based on practical consideration.

I prefer to use C to write core loops to improve efficiency now.
Most of the time, Keeping the C data structure simple enough , let Lua
access to them easy. And we can rewrite the core loop at any time with
C.

My latest attempt is luaecs ( https://github.com/cloudwu/luaecs ), It
provides two sets of APIs (lua and C) to access the same data
structure.

> Just a shame that it still ended up doing a lot of harm for the adoption of Lua 5.3 and above.

I agree. From a language design perspective, lua 5.4 is much better
than lua 5.1 , and luajit only brings a slight performance improvement
but it limits many projects to the ancient lua version.

--
http://blog.codingnow.com

[Coda Highland]

The performance delta when running vanilla Lua code is relatively small, yes, but there are two things that are where LuaJIT really starts to shine:

* Code specifically optimized for LuaJIT can see a more significant performance benefit.

* LuaJIT's built-in FFI can be a lot faster than luaffi.

LuaJIT's bytecode is also portable, and my understanding is that Lua's bytecode isn't portable across architectures by default.

So... Yeah, if you're trying to write code that works in both Lua implementations, then there's no benefit. And if you're writing code that doesn't need to be performance-sensitive, then there's no real point. But if you're okay with changing your usage patterns to take advantage of the things that LuaJIT specifically does well, then that's where its value really lies.

/s/ Adam

[Andrew Starks]

On Fri, May 2, 2025 at 1:12 PM Coda Highland <chig...@gmail.com> wrote:

The performance delta when running vanilla Lua code is relatively small, yes, but there are two things that are where LuaJIT really starts to shine:

* Code specifically optimized for LuaJIT can see a more significant performance benefit.

* LuaJIT's built-in FFI can be a lot faster than luaffi.

LuaJIT's bytecode is also portable, and my understanding is that Lua's bytecode isn't portable across architectures by default.

So... Yeah, if you're trying to write code that works in both Lua implementations, then there's no benefit. And if you're writing code that doesn't need to be performance-sensitive, then there's no real point. But if you're okay with changing your usage patterns to take advantage of the things that LuaJIT specifically does well, then that's where its value really lies.

Since we're all off topic here, I'm still pretty excited to try Pallene some time. I don't get to program much now-a-days, but this seems like a better approach to accelerating scripting applications than LuaJIT.

https://github.com/pallene-lang/pallene

-Andy

[Sainan]

Ah yes, I love compiling my scripting languages, that's why my scripting language is called C/C++ and I don't embed a language specifically for scripting... oh wait.

-- Sainan

[云风 Cloud Wu]

Coda Highland <chig...@gmail.com> 于2025年5月3日周六 02:12写道：

>
> The performance delta when running vanilla Lua code is relatively small, yes, but there are two things that are where LuaJIT really starts to shine:
>
> * Code specifically optimized for LuaJIT can see a more significant performance benefit.

In my opinion, If we can spend our energy to optimize the code for
luajit, then it is better to find the part that needs to be optimized
and rewrite it with C code.
It can usually achieve better performance benefits (less uncertainty)
and make the software structure clearer.

> * LuaJIT's built-in FFI can be a lot faster than luaffi.

I don't like FFI, because this usually means that the core module
lacks good encapsulation, and data structure is not well designed.

When writing a C library, we usually need to think carefully about
which parts are more suitable to be placed in C side and what data
structures are more suitable for access from both C side and Lua side.
FFI makes these thoughts sloppy.

--
http://blog.codingnow.com