Yes, maybe I am not as experienced as the most of you here (no, it's a fact, exactly).
But I love Lua (not luaffi, not some dialect, just Lua). Why?
It gives me possibilities to do things which helps me in my daily work - it's portable, small and fantastic modular. It also gives me possibilities to do and use things which should maybe don't be used - like luaffi - doing rock solid stuff I can trust. And if some library doesn't tend to be portable, I can try to fix it (no, i don't want to fix or extend luajit).
If someone would try to criticize how things can be done - yes, you are right, absolutely. Some things shouldn't be done in correct software design.
But - if it's stable, if it's working, if it helps to shift down the development time...?
Roberto, with all respect, can you explain why luaffi isn't a "serious option" but luajit with FFI is?
Sometimes, runtime speed isn't everything. We have used luaffi on Windows, embedded with PUC Lua as a framework in our own really-custom-dll. It will _never_ win a speed and benchmark contest, but we have never implemented a software project with a specific demand as fast as with this project - with a satisfied customer. Also, "in-system-bugfixing" was never that easy.
What means serious here?
Why is luajit with luaffi so much better (which still is anchored to 5.1)?
On 7 March 2018 at 15:23, Pierre Chapuis <catwell@archlinux.us> wrote:
Not only that, people write code that assumes it runs on LuaJIT and
uses the FFI anyway...
hey, the FFI is the nicest thing of LuaJIT! in fact, it happens to me
a lot that i start a project in a somewhat modern Lua, and then
appears something that would some C... at that point I have to
consider: is this a "serious thing, where i do care about the users?"
then I use the Lua C API. if it's a quick and dirty thing, then i
switch to LuaJIT and use the FFI. (no, i don't consider luaffi)
luaffi is not a serious option, and cannot be; the whole philosophy of
FFI demands a compiler. FFI is what made LuaJIT definitively a fork of
Lua.
-- Roberto
