piccolo

You responded to a post about https://github.com/kyren/piccolo, not to the top level post about an entirely different project. The word "blazingly" exists nowhere on piccolo's github page according to ctrl-f.

As others have noted, this is not actually a Lua engine written in Rust. It is a wrapper over existing C/C++ implementations of Lua. There is, however, an actual Lua engine written in Rust. It is called piccolo.[0] [0] https://github.com/kyren/piccolo

There is also Lua implementation in safe Rust - Piccolo[1] [1] https://github.com/kyren/piccolo

I've used rlua (mlua is a fork of it) and mlua extensively. The part you've shown is absolutely the easy part. Doing anything interesting with the runtime after that is much less obvious. Even something as simple as 'load a lua file that returns a table of functions and use those functions from rust' is surprisingly hard to figure out. (I know, I just did that a few weeks ago.) I haven't used Rhai, but Lua has a lot of impedance mismatch with Rust that could be avoided with a fresh language. (Or maybe even just a fresh implementation of Lua, like piccolo is trying: https://github.com/kyren/piccolo)

For a pure Rust answer to “how to make a primarily-safe gc-lang in Rust”, see Piccolo (Lua) with its ‘Stackless VM’: https://github.com/kyren/piccolo That’s not to say Piccolo couldn’t theoretically benefit from having its (already isolated) unsafe parts rewritten in Zig, but that’s up to the Zig developer community to chip away at with upstream contributions.

I strongly encourage people interested in this topic to look at the piccolo VM that has been referenced in the post. It is a fascinating exploration of how a stackless VM can work in Rust. It uses "sequences" (think a bit like a future or promise) to express control flow that yields or calls into other VM methods. Particularly for a little while now it has the concept of an async_sequence [1] which allows one to abuse (?) async/await where it will create a shadow stack to make this code more readable. I find all of this quite exciting because there are not that many stackless VMs out there that are readable and not a massive usability hazard if you do something wrong. [1]: https://github.com/kyren/piccolo/blob/master/tests/async_seq...

There's Lua implementation [1] in pure Rust, by the way. [1] https://github.com/triplehex/piccolo

I wish there was a Lua implementation in pure Rust (I understand about likely performance degradation compared to LuaJIT). There's incomplete Luster[1], but it's still unusable. [1] https://github.com/kyren/luster

There's also Luster[1]. [1] https://github.com/kyren/luster

There's also Lua implementation (incomplete) in Rust - Luster[1]. [1] https://github.com/kyren/luster

Tossing my hat in for Passerine [1]. Gorgeous ML inspired syntax. Written in Rust, and I suspect scripting Rust libraries is in the cards. Dreaming here: Lua is a fantastic scripting language, but the Rust FFI isn’t as ergonomic as it could be. Enter Luster [2], which is basically LuaJIT rewritten in Rust. Embedding a scripting language in a Rust application gives you tons of power (e.g. scripting Rust structs from Lua [3]), and setting this up isn’t terribly difficult. [1]: https://github.com/vrtbl/passerine [2]: https://github.com/kyren/luster [3]: https://git.sr.ht/~ioiojo/kiwi

> The use of a special kind of lifetime annotation, where the lifetime has to match exactly, can be used to get around this limitation. This is already expressible in Rust, using invariant lifetimes. You can hand someone an opaque invariant lifetime, let them build a mutable cyclic data structure with it, and then pass that data structure around. This use of invariant lifetimes, called "generativity," is described in more detail here (https://raw.githubusercontent.com/Gankro/thesis/master/thesi...) in section 6.3, which describes a way to use lifetimes as unique tokens for all sorts of use cases. And even more closely aligned with what the article is talking about, Catherine West has put together a library that uses generativity to provide a safe interface to a garbage collected heap, as part of a reimplementation of Lua: the `gc-arena` c