LuaJIT Lua Gulf? (Was: Why I leave Lua..)

[steve donovan <steve.j.donovan@...>]

On Thu, Jul 10, 2014 at 9:00 AM, Tim Mensch <tim-lua-l@bitgems.com> wrote:
> This is where I ended up. LuaJIT is very stable and extremely fast. The FFI
> is awesome.

There is a compatible library [1] for regular Lua, although I can't
attest to how complete it is and of course it will be much slower.
There is a big difference in _thinking_ between regular Lua and
LuaJIT;  the FFI is faster than calling C extensions and generally
people often avoid C because it can mess with the tracing compiler.
Although even when not jitting, the hand-coded interpreter is going to
give that extra factor of 2 or 3 times - *if* the platform is
supported by LuaJIT.  It's a big undertaking to support a new
processor in LuaJIT, whereas with regular Lua it's relatively simple.

When Lua is used as an embedded scripting language however, often one
just doesn't need the raw performance since the scripts are
orchestrating operations performed in the core.  Embedding LuaJIT can
apparently be more bothersome, as well as larger.

> I think there's a danger in stock Lua going in directions where Mike Pall
> doesn't want to follow.

The 5.2 compat options are pretty good (__ipairs, __len) but _ENV will
never happen and __gc is waiting for the next generation GC.

[1] https://github.com/jmckaskill/luaffi