IIRC Snabb uses LuaJIT to handle network packet filtering, so that's a
project with some pretty stringent performance requirements that a
non-compiled language would probably have difficulty meeting.
Right. Snabb has a total processing budget of a few hundred CPU cycles per packet to e.g. read it from the network, route it, filter it, transform it, and write it out again. Our code has to be competitive with C written by Intel engineers and aggressively optimized for their latest CPUs using intrinsics and other compiler trickery. This is very challenging with LuaJIT but by some miracle we are succeeding - even in most of the inner loop code.
This application would definitely not be viable with an interpreter due to the practical performance requirements.
(I'm not really sure whether Snabb counts as a "Lua" application or only a "LuaJIT" application. I am a little curious about whether Lua aspires to be a single implementation language or a Lisp-like family of languages or whether it's meaningless to anthropomorphize it like that. I should reread the HOPL paper for context ... :))
