I'm keen on all kinds of embedded systems. An electrical engineer by training, I've co-founded two startups and worked in agritech IoT, satellite comms, and Forth/Python/Lua language embedding.
I ride a unicycle and dream of building a self-propelled, self-bouncing, autonomous basketball. But I've never gotten around to it, because I've been distracted by the way to know the Creator-God … and, me-oh-my, but that's a marvellous possibility!
I do embedded systems design: both hardware and software – preferably close to the metal. But do be aware that I'm often full-up.
Here's a copy of a helpful comment by reddit user gladiatr72 : Nothing to flame you for, really. (regarding the closing statement of the blog post for those that haven't looked at it). I think you might be looking at the whole 5.1 v 5.4 thing through the wrong lens vis openresty. If you search for the topic in the openresty (closed) issues on github, I believe Yichun Zhang has made a clear case why such a shift is not on their radar. Immediately, there are the current performance benefits to LuaJIT but there is also the element of 5.1 being 100% feature/structure stable. (also have a look at the FAQ on their website or through the mailing list archives for different iterations) Even if Haoran Xu's efforts (which are cool af) towards creating a fully jit'able compiler that can match|outmatch LuaJIT, any performance benefit would need to be impressive enough to justify replacing a language/stable Lua with one that will inevitably drift. From what I've seen, where YZ addresses this sort of inquiry, he's much more interested in solving new problems than revisiting old ones. If you're interested, you might have a look at the LuaJIT mailing list . Mike Pall has offered some detailed dives into the how's/why's of which code paths(?term) benefit from JIT compilation. Anyway, thanks for the write-up. Too few posts regarding Lua at this level of the stack.