Re: TechRepublic article about languages to avoid in 2018

[Dibyendu Majumdar <mobile@...>]

On 9 March 2018 at 14:09, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>> > 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.
>> >
>>
>> Did you mean that luaffi is not a serious option for inclusion in Lua
>> (because it is not ANSI C etc.)?
>
> By "option" I meant that luaffi is not a real alternative to ffi
> in LuaJIT. The use of ffi in LuaJIT makes programs much faster
> (when compiled), while the use of luaffi in Lua makes programs much
> slower. That is not a fault of luaffi; at most it is a fault of C.
>

I haven't benchmarked against the standard Lua C api - are you saying
it is slower than that?

LuaJIT's ffi of course has a performance angle to it - but an ffi
interface is also just a convenient way to invoke external code; so
performance is not necessarily the main factor when using luaffi with
Lua which doesn't have a JIT.

>
>> LuaJIT's ffi is a library and I am not sure why the inclusion of a
>> library should cause LuaJIT to be classed as a 'fork' - although
>> 'fork' is problematic word in my view anyway.
>
> ffi in LuaJIT is not a library.
>

It is certainly classed as a Library by LuaJIT, and behaves like one -
i.e. it is not part of the language. Of course it is deeply integrated
to get better performance but that doesn't necessarily take away from
its nature. I believe it is also optional.

Anyone using ffi is writing code that cannot be run in Lua of course,
but that is where luaffi comes in.

Regards
Dibyendu