That's a very different approach. This is closer to using Lisp to generate C, whereas Lua+C usually involves a multilayered design: you write your engine in C or C++, write or generate a simple Lua wrapper for its API, and then the do logic in Lua, moving hotspots to C as necessary. (<a href="http://c2.com/cgi/wiki?AlternateHardAndSoftLayers" rel="nofollow">http://c2.com/cgi/wiki?AlternateHardAndSoftLayers</a>, as they say.) As a bonus, the cross-language boundaries are often natural seams for containing complexity.<p>TCL was also designed with this style of programming in mind, and John Ousterhout describes it pretty well (<a href="http://www.vanderburg.org/OldPages/Tcl/war/0009.html" rel="nofollow">http://www.vanderburg.org/OldPages/Tcl/war/0009.html</a>).<p>FWIW, LuaJIT is only available for i386 at the moment, though amd64 porting is in progress. Standard Lua is still pretty fast, and it's great for prototyping. It's a good idea to get algorithms and overall design right before spending much time on low-level tuning.