My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.
For example, what’s the performance like?
In a mix of official and unofficial benchmarks wall clock performance is ~1.4x as fast as C Lua and the memory usage is ~1.7x.
So performance is worse to be clear but within range. There’s some performance improvements I haven’t gone for yet that would get it down to ~1.1 I think.
> My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.
I think you could stop right before the syntax extension.
If you have any Lua use cases let me know I’m looking for more real world use use cases to justify the effort here.
I think where it would be most helpful is converting a codebase and being able to easily run tests to ensure behavior is the same.
I created a github gist https://gist.github.com/ianm199/5ba0366376eca673142e1f0c79b4... that explains what is practical (I used AI for this to be clear feel free to skim).
Do you have a use case in mind? Would love to chat or take a look at an github issue if you create one.
> Do you have a use case in mind?
Two, 1) upgrading Lua code on a module by module basis 2) Using a newer library on an older codebase. I know those are really two takes on the same problem. I understand why your system doesn't, but at least yours is more flexible than mlua.
I understand why this hard and why it just doesn't work like this out of the box. Lua minor versions are really major and the semantics really does change.
I also don't think what I am asking for is all that necessary, more of a cute language and runtime flex. If the Lua total addressable market was 100x what it is with lots of code on older versions that needed to run side by side then maybe.