It was thus said that the Great Dibyendu Majumdar once stated:
> Related to my post about why I have not used the JIT technology in
> Ravi for my project (yet), is the question: do we need a JIT for Lua
> at all?
> I have no data points to tell me under what conditions a JIT makes
> sense, apart from artificial benchmarks. The most obvious use case is
> games programming I guess where the highest performance is needed, but
> I am not a games programmer and do not know whether interpreted Lua is
> good enough in this case.
I see LuaJIT useful in cases of heavy mathematics, who's speed can rival
that of C (I have some Lua code to generate a Mandelbrot set---running under
LuaJIT it's easily the same speed as a similar program in C) since LuaJIT
can optimize the heavy loops to take advantage of runtime information
(certain values never change in the loops so we can do constant propagation,
> In my opinion, having worked on Ravi and in my usage of it, Lua is not
> a general purpose language that you would use to build a large scale
> application. This is not because of any deficiency in Lua, it is more
> that large scale development is better done in statically typed
> languages like Java, C#, Go, Swift etc. The cost of developing complex
> applications in a dynamic language is just too high. I know that many
> folks on this list will probably disagree with this view, but leaving
> aside your love for Lua and your wish to use Lua everywhere, would you
> still use Lua as a general purpose application development platform?
At work, we use Lua to parse SIP messages (using LPeg), and based on the
information given, formulate a request to a backend server to do the
"business logic" , receive the response from said backend server, and
reply with a new SIP message containing the information from the backend.
And this is major---it's part of the Monopolistic Phone Company's call flow
(that is, real phone calls).
Granted, it's not a large application (6300 lines of Lua, excluding third
party code and modules written in C, which itself if a few thousand lines of
code) but it's still an application making our company money. Running PUC
 Caller Name ID---that is, for a given phone number, return an actual
name associated with the account.
 Even though it's all Lua 5.1, we can't use LuaJIT because the code
runs on the SPARC architecture , which LuaJIT does not support.
 A legal requirement for the hardware to be NEBS compliant, and Sun
SPARC machines match that requirement. If we could get non-SPARC
machines that were NEBS compliant, we would in a heartbeat.