I've looked at luajit, terra, and now raptorjit; and I always come to the same conclusions.
1) this is the wrong optimization (more below)
2) Rio's runtime is very good (enough for now, at least)
3) the next big step like this is to make an interpreter in Rust, not necessarily a parser/ast generator, but just a runtime, and I'm not in a rush for this
the right optimization is to do low-level work in a systems language.. in my case Rust, where rLua has a great wrapper for puc Lua. only use Lua as a scripting language to call those lower level functions.
right now on github, you can see my Lua bindings to Rust's libraries for web server, web client, libsodium functions, jinja rendering, string transforms, set operations, and more. all of that work is done in Rust, and controlled by Lua. it's faster than any Lua you've ever seen.
You clearly don't understand terra then. Terra is a system language that mimics Luas syntax and uses it as a preprocessor. The only thing that makes it different from, say, C, is that the compiler can actually run the code it generates immediately, and outputting an enclosed executale is an option, but not the default.
As for PUC Lua, yes, it's perfectly ok for most things when you're mostly scripting and using C for the heavy lifting anyway, like when you're building a scripting language into an already existing game engine or program.
LuaJIT was always meant to fill the in-between role (which is, arguably, the broadest one) where you can't be bothered to write a full C application to host your Lua code but still need more speed than you get by just running a whole program in PUC Lua.
> where you can't be bothered to write a full C application to host your Lua code
This Rust code I linked to is an application framework. It makes several of Rust's most powerful libraries available to Lua, which should greatly improve development speed. I'm using it to build an event-based Lua web framework on top of it. (also there) Development of other network applications should also be very smooth, afaics.
Yeah thats a different use case somewhat like a modern version of openresty but built around a set of libraries rather than inside Nginx. There may still be a case for some applications for a jit compiler for the Lua parts but that depends on the application.
I don't agree with this at all. First of all, something feels off when you talk about right and wrong optimization without taking context into account. RaptorJIT grew out of the Snabb switch community. With that in mind, Rust+Lua isn't anywhere near pure Lua in terms of development speed, minimalism, simplicity and flexibility. Luke Gorrie has come out of the Lisp community so I have to imagine that these criteria are very important to him.
Systems language doesn't really mean anything by itself, so you sound very dogmatic when you talk about "right" here. The Lisp machines were implemented in Lisp. Is Lisp a systems language?
> Rust+Lua isn't anywhere near pure Lua in terms of development speed, minimalism, simplicity and flexibility
I hope you're wrong about this one. I guess I might have some trouble gaining stake holders from even Lua supporters who view it as a best language for every layer. But Rust has an incredible amount to offer Lua, especially when used primarily as a higher-level scripting language, for glue code.
Except rlua goes out of its way to look like anything but the Lua C API. So you've immediately lost all productivity for people who know that abstraction well. Additionally, anyone whose spent any significant amount of time in that space knows of the amateur alternatives, and this looks no different.
1) this is the wrong optimization (more below)
2) Rio's runtime is very good (enough for now, at least)
3) the next big step like this is to make an interpreter in Rust, not necessarily a parser/ast generator, but just a runtime, and I'm not in a rush for this
the right optimization is to do low-level work in a systems language.. in my case Rust, where rLua has a great wrapper for puc Lua. only use Lua as a scripting language to call those lower level functions.
right now on github, you can see my Lua bindings to Rust's libraries for web server, web client, libsodium functions, jinja rendering, string transforms, set operations, and more. all of that work is done in Rust, and controlled by Lua. it's faster than any Lua you've ever seen.
https://github.com/foundpatterns/torchbear