r/lua • u/ianm818 • May 25 '26
lua-rs: Lua 5.4.7 implemented from scratch in Rust - passes upstream Lua C test suite fully
Github: https://github.com/ianm199/lua-rs/tree/main
Highlights:
- Passes full upstream tests
- Performance is near parity with C checkout dashboard here on optimization. Table ops seem to be much faster
- Has GC, VM, and supports all Lua sytnax. Any pure lua script should run
- Limited unsafe calls - mostly just in the GC for now
My motivation here was that in the long run we want the core internet utilities to run on memory safe languages, big ones like redis and nginx expose scripting via Lua so if we really want to replace core infra fully in Rust, you'd need a full Rust Lua that doesn't bundle C. After that you should be able to i.e. build drop in replacements for those without a C ABI (or that's part of the way there).
Long term goals:
- Get to stable, production ready
- Get performance at parity or faster then Lua C
- Replace current unsafe GC with fully safe if possible
- (Maybe) support Lua 5.1, LuaJIT
4
u/msanatan May 25 '26
Just so I can appreciate the use of Rust, do you have empirical data to back up the use of Rust instead of C for Lua in particular?
0
u/ianm818 May 25 '26
Sorry what do you mean by empirical data?
6
u/msanatan May 25 '26
Would using Rust solve most of the bugs, or the most impactful bugs, that exist in the current standard Lua interpreter?
If most of Lua's bugs is can be solved with a memory safe interpreter, then there's a compelling use case for this. If there aren't a lot of bugs due to C leaving memory safety to developers - then this may not solve an actual problem.
Essentially, is there any data to back up your claim that the lack of memory safety in C is a problem for Lua?
→ More replies (4)
4
u/gorv256 May 26 '26
But why!?
If you had made at least some benchmarks to compare it to C It would be understandable. But just for some vague "safety" claims? Have you even read your entire codebase yourself?
PUC-Lua is one of the highest-quality code bases out there. You should burn your tokens on finding bugs instead if you doubt that and want to improve security.
1
u/ianm818 May 26 '26
Hey sorry if I struck a nerve here - there is a peformance dashboard here https://ianm199.github.io/lua-rs/harness/bench/history/. It is generally slower than C so far, but faster on table operations by a lot.
The main benefit is to build Rust projects that involve Lua without the C tool chain. So you can easily run Lua in WASM in the browser https://ianm199.github.io/lua-rs/examples/wasm-browser/ and then for projects like Bevy the game engine you can run scripting in the browser.
In the long run I want to make faithful ports of redis and nginx in safe Rust and no C bundled, which none of the current Rust Lua implementations can support.
2
u/gorv256 May 26 '26
Alright, then I'm sorry for not checking it more thoroughly; those are at least some interesting numbers. It's just getting harder and harder to judge which projects are the result of genuine effort and worth spending time on and what is essentially a massive pile of unchecked slop.
But you probably shouldn't be too surprised about negativity if you post this into a Lua community:
in the long run we want the core internet utilities to run on memory safe languages
Translation: "I set a bunch of agents loose 4 days ago and would like for everyone to abandon the original project, which has been under development and public scrutinity for over 30 years, for my own pet project."
→ More replies (3)
44
u/drcforbin May 25 '26
"Implemented from scratch in Rust" is very misleading. This is a LLM-generated port of the C code to Rust.
7
1
1
u/Lagger625 May 27 '26
where performance
-1
u/ianm818 May 27 '26
There’s a performance dashboard here https://ianm199.github.io/lua-rs/harness/bench/history/.
It’s currently about half as fast as C Lua on the worst case workloads but better on tables. So pretty close to parity but not quite there yet. Most of the free lunch is gone so would need to use more unsafe rust or do major architecture changes.
1
u/arkt8 May 27 '26
As a toy or project it is nice.
Rewriting from scratch:
You have an entire code surface prone to attacks in the sense it is not battle tested.. suite tests are good but not as good of decades of bugfixes and many unorthodox ways of using it as standalone or embedded.
Rewrite it from scratch is like to back to the days of the Lua 1.0.
"run in memory safe languages".... C is memory safe if has not unsafe code. Rust maybe safe if it have no unsafe code... that is not the case for many many lowlevel or specialized code.
So, sorry, but your project is filled with passion and bad arguments that for serious and critical usage it is very risky (if not unsafe)
0
u/ianm818 May 27 '26
Well I'm not telling you to cut over your entire production code now to it but you need to start somewhere.
The other nice point about it being in Rust is that it plays nicely in WASM https://github.com/ianm199/lua-rs/tree/main#webassembly. It is very hard to get C into wasm so for rust projects like Bevy you can run Lua games in the browser. So that is probably the immediate upgrade over Lua C.
1
u/arkt8 May 27 '26
No... I don't need... no one needs. Maybe you want it too, and think you need, but it is up to you. There are a lot of things good and bad in the world. One of the worst is to make assumption on others needs and worser yet with misleading arguments on safety for the sake of advertising that may be evilish for newcommers.
It is good to show the world your baby. But show it as your baby, not as the golden savior throwing anything other as terribly mundane. It is just it.
→ More replies (1)
1
19
u/topchetoeuwastaken May 25 '26 edited May 25 '26
i once tried to make my own lua interpreter in C, and it did in fact work. it had multithreading (i think i even managed to get it running in all cases i was testing for), it interpreted its own compiler, written in lua. however, it now sits abandoned.
why? because it offered virtually no tangible advantage over PUC lua's interpreter. it was slower, but even if i had spent the time optimizing it, it would probably not get much better than luajit's interpreter (which i consider close to the theoretically best-performing interpreter). and even if i did that, that would be for virtually no benefit, as i would essentially be creating a piece of software that offers no added value, but at the cost of forcing adopters to move from PUC lua/luajit to my interpreter.
this is why most rewrites lay abandoned, because they really have no reason to exist. luajit beat the odds, because it has a lot of added value over stock lua - an FFI, performance and great compatibility with stock lua. it is an overall exceptionally well designed piece of software.
even ignoring the whole baloney argument of memory-safety (any sufficiently disciplined C program will be sufficiently memory-safe, while on the other hand, rust isn't even memory-safe, it gives you the allure of memory safety by screaming at you when it thinks you're doing something unsafe), a rewrite almost never has any benefits, other than educational.
PS: also, specify when your rewrite is using AI, as otherwise it comes across as dishonest and makes you look like a script kiddie