> LuaJIT's C FFI is ... Indeed LuaJIT's FFI is a very cool and usable, but it does one huge drawback: it basically ties you to LuaJIT. I'm not trying to diss

> LuaJIT's C FFI is ... Indeed LuaJIT's FFI is a very cool and usable, but it does one huge drawback: it basically ties you to LuaJIT. I'm not trying to diss LuaJIT—it's a wonderful and impressive JIT implementation, and for some applications, irreplaceable—but compared to the standard Lua implementation, LuaJIT is (1) less portable, (2) more complicated, and (3) has various implementation drawbacks.† In addition, of course, there are other alternate Lua implementations which have their own set of tradeoffs. Essentially, it's very nice to be able to switch Lua implementations depending on the circumstance. With normal usage, LuaJIT is carefully designed to make this possible (indeed, easy: one need only change the library one links against, it's not even necessary to recompile one's app), but once you start using things like FFI, that ability is lost. There's a port of LuaJIT's FFI interface to standard Lua, but it's also not portable, and because it will have very different performance characteristics than FFI in LuaJIT (which can "compile out" FFI accesses), it's not really a drop-in replacement for it, and I think not nearly as compelling. † The one that's bitten me in the past is that LuaJIT has a much smaller limit on addressable memory than standard Lua because of the particular design of its nan-encoded object representation. There are some input files for my Lua-using app that will only work when I compile with standard Lua, because using LuaJIT will run out of memory; those are times when I'm very glad I didn't commit to a LuaJIT-only design...