Hello!
On Wed, Nov 27, 2013 at 5:25 AM, Bertrand Mansion wrote:
> But I am not too eager to use LuaJIT because for me it is an independent
> project driven by a single person (AFAIK)
BTW, Nginx used to be a single-person project as well :) And ngx_lua
and the openresty bundle is also (officially) maintained by a single
person ;)
> and all in all, it is very
> different from Lua. It doesn't follow the same release cycle and doesn't
> implement new Lua features and it comes with a different interface.
LuaJIT 2.x keeps compatibility with the Lua 5.1 language for a good
reason: later Lua language revisions break compatibility with 5.1 both
on the Lua language level and on the C API level, and it is just too
scary for enterprise users to update all their existing Lua (5.1) code
base upon every major Lua language update. After working for big
Internet companies for years, I actually very much appreciate the
decision made in LuaJIT.
BTW, LuaJIT does support quite a few new Lua 5.2 language features
that do not break compatibility with 5.1, by means of the
-DLUAJIT_ENABLE_LUA52COMPAT build option.
Also, as you have mentioned, LuaJIT implements a lot of brand new
features like table.new(), table.clear(), the bitop extension, the ffi
extension (and also more to come like the string.buffer API!) that are
invaluable to OpenResty and also web development in general. I think
all these new features help shaping the Lua language in a good way,
with performance in mind. I believe this is always a Good Thing.
Otherwise I may leave the Lua community to be honest.
> So
> that's actually a different language. FFI is also not compatible with
> regular Lua.
>
Almost every major standard Lua interpreter revision implements a
different language (like it 5.1 and 5.2). When the standard Lua
language keeps changing itself, how could you even define "regular
Lua" unambiguously?
> So I was wondering about the direction that was taking the Openresty
> project,
The OpenResty project was originally created for solving performance
problems in a big Internet company with really heavy traffic. We chose
Lua because LuaJIT's performance could fit our needs well at that
time. Actually I only started learning the Lua language seriously
after I started hacking on the ngx_lua module ;)
So the future focus of OpenResty will still be on solving real-world
problems in a very pragmatic way, especially performance problems,
rather than simply keeping compatibility with everything just for
completeness or fun :)
> in particular :
>
> - Is LuaJIT going to become a requirement ?
For the ngx_lua module, I'll keep the support for the standard Lua 5.1
interpreter because pragmatically it is always good to have multiple
Lua implementations to compare.
But not all Lua libraries in the OpenResty world will support the
standard Lua 5.1 interpreter, specially for those relying on LuaJIT
FFI like lua-resty-string and lua-resty-core. Forking every Lua
library's code base for every major Lua language revision (like 5.1,
5.2, and 5.3) is just too crazy and impractical.
> - Is FFI going to become the standard to make modules ?
It'll become the recommended way to create new Lua modules interfacing
with C. There is no single "standard" way of doing things in the
OpenResty world, and probably will never be :)
> - Is there any chance that Lua 5.2 or 5.3 will be supported ?
>
To be honest, I'm reluctant to add support for Lua 5.2 and beyond to
the ngx_lua core, because it will make the code base messier without
much real gains. (The standard Lua interpreter can never fit our needs
regarding online performance.) But still, I'm open to patches for Lua
5.2/5.3 compatibility from the community :)
Best regards,
-agentzh
