3 ms·

> 5.1 / 5.3 -- "don't see any unique selling point" -- "there are a couple of forks" Doesn't that show that the actual users of Lua and the authors have drifte

> 5.1 / 5.3 -- "don't see any unique selling point" -- "there are a couple of forks" Doesn't that show that the actual users of Lua and the authors have drifted apart, and the former are not willing to commit to a hard fork or taking over development? Or both sides could come together to form a much-beloved committee. The curse of "good enough". > quirks / fastest I think you misunderstood: Yes, it is fast even without LuaJIT, and super easy to embed and integrate - which is why this slow fading away into the embedded only realm would be quite a shame. But it is also "quirky", and adding some (optional, possibly slower) syntax sugar over it could make it more appealing. Sure, Lua-fans will argue that tables are better than anything, but for those who just want to transfer existing language knowledge are hard to convince, and setmetatable makes everything even weirder.

Rochus 6y ago
> the actual users of Lua and the authors have drifted apart So what? It has an MIT license, and there are obviously different communities with different requirements. > it is fast even without LuaJIT Not really. The PUC Lua VM is even slower than Python (in geometric mean) according to https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... LuaJIT in interpreted (not JIT) mode is still four times faster than PUC Lua (see http://luajit.org/performance.html http://luajit.org/performance.html). > this slow fading away into the embedded only realm would be quite a shame. I assume you mean "embedded use in applications" (i.e. not embedded systems). That's exactly what Lua was designed and built for by its original authors. An that's how it is mostly used. > adding some (optional, possibly slower) syntax sugar over it could make it more appealing Lua can do surprisingly much for this lean and simple syntax. If instead you prefer a baroque, pretentious syntax like Python or TypeScript, and are obviously satisfied with Python's performance, you already have a well established solution. And as I've demonstrated e.g. with https://github.com/rochus-keller/Oberon https://github.com/rochus-keller/Oberon you can replace Lua by a more complex language and still profit from the performance and leanness of LuaJIT.

Rochus 6y ago

> the actual users of Lua and the authors have drifted apart So what? It has an MIT license, and there are obviously different communities with different requirements. > it is fast even without LuaJIT Not really. The PUC Lua VM is even slower than Python (in geometric mean) according to https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... LuaJIT in interpreted (not JIT) mode is still four times faster than PUC Lua (see http://luajit.org/performance.html http://luajit.org/performance.html). > this slow fading away into the embedded only realm would be quite a shame. I assume you mean "embedded use in applications" (i.e. not embedded systems). That's exactly what Lua was designed and built for by its original authors. An that's how it is mostly used. > adding some (optional, possibly slower) syntax sugar over it could make it more appealing Lua can do surprisingly much for this lean and simple syntax. If instead you prefer a baroque, pretentious syntax like Python or TypeScript, and are obviously satisfied with Python's performance, you already have a well established solution. And as I've demonstrated e.g. with https://github.com/rochus-keller/Oberon https://github.com/rochus-keller/Oberon you can replace Lua by a more complex language and still profit from the performance and leanness of LuaJIT.