Here are two real-world examples of using Rhai:
I've embedded Rhai in Glicol to support sample-level audio synthesis, and the performance is [acceptable]. Real-time audio is very computationally intensive, after all.
I've tried various embedded scripting languages in Rust, but Rhai probably has the best documentation and playground.
For reference, see this survey:
https://www.boringcactus.com/2020/09/16/survey-of-rust-embed...
Recent Koto Lang also looks promising:
Another example using Rhai that was posted here a week or two ago: this (in-browser) 3D modeling software using Fidget.
Not going to dissuade anyone from having fun hobby projects.
But legitimate question: why would I choose this over Lua, which is probably faster, super easy to embed and has a larger ecosystem.
(Please, saying "Rust" or memory-safety can be assumed already to be understood, but not considered compelling arguments)
I haven't tried Rhai and I wouldn't call myself anything more than a casual Lua user, but from a glance, these could be some reasons I see others using Rhai instead of Lua:
- Closer to Rust syntax/data structures, so easier if you already know Rust but don't know Lua
- Built-in serde (popular Rust de/serializer) support, if you need that
- Not sure if existing Rust<>Lua crates have it, but the debugging interface looks like the beginning of something useful (https://rhai.rs/book/engine/debugging/)
- Made in Rust, so again, if you already use Rust (which you do, if this crate is an option) it'll most likely to be easier to change for your needs, than modifying a Lua runtime
Personally, I'd probably still go for Lua rather than something like Rhai, if I had to choose something for algol-like scripting support. Otherwise I think Steel (https://github.com/mattwparas/steel) looks like the most useful scripting environment for Rust currently.
I’m already writing a Rust system. I’ve tried integrating with mlua. It works, but Rhai is simpler to embed. Simpler to build.
(I also tried Piccolo which is very cool but also not simple.)
Rhai also doesn’t include a lot of complexity that Lua does. It encourages you to write extension types in Rust, which is what I want.
Rhai doesn’t have GC, just refcounts. Rhai also can disable a lot of features, say if you just want an expression language.
I use it to write trading logic. I like that it’s stripped down and simple.
> I’ve tried integrating with mlua. It works, but Rhai is simpler to embed. Simpler to build.
I'm curious what challenges you faced when embedding Lua via mlua? I've done it many times in projects and I've always found it to be trivial.
$ cargo add mlua --features lua54,vendored
let lua = mlua::Lua();
I've worked with moai (1) reasonably extensively, and the lua in it is not easy to use and sucks.
Specifically, a project that is composed entirely of lua with no other dependencies is indeed very easy to build and maintain. I agree.
However, my $0.02 would be that if you plan to have a large project with many 3rd party dependencies, then cmake, visual studio, C++, lua and the time spent jumping between them and maintaining those dependencies in a custom build toolchain will cost you more time and effort than the benefits that lua offers (2).
...and you do, indeed, need to do that, because c++ lacks a centralized package ecosystem and unified build tooling; and as operating systems change, existing builds stop working.
So, yes, you may consider my answer to be 'rust'; but the actual answer is 'not C++ and not cmake'.
That all said, lua is a more mature better system than this is currently, with good resources online and an active community. In cases where a small dependency tree can be maintained, it's still the best choice I'm aware of.
I'm simply pointing out that there are reasons you would pick it over lua, and I think they're quite compelling for cases where the future dependency graph of your project is unknown / unknown.
[1] - https://github.com/moai/moai-dev
[2] - ...and yes, I'm aware that moai is especially egregious in this regard. I get it.
There are a bunch of crates available for scripting in Rust/Bevy (Rhai, Rune, Luau, Teal, etc), anyone who've tried specifically Rhai with specifically Bevy before and could share their experience?
When I last read about Rhai it was apparently very slow such that it was simply faster and more ergonomic writing scripts in Rust itself, has that changed?
According to the documentation it evaluates by walking the ast, so yes, this is considered very slow. The readme also mentions 1 million loop iterations in 0.14s (140ms). Even my unoptimised naive lips like language [1] (also implemented via a ast walker) does the same in 28.67ms - so yes id consider this pretty slow.
As someone who is also implementing a naive "walk the AST" evaluator for lisp, what would be considered OK/fast/not-slow in the case for 1 million loop iterations? Would ~30ms be considered fast or "not-slow"?
It just mentions a loop, so id say for a loop without any content, it should be less than 50ms, but as the other commentor said, it depends on your hardware and a better measurement is to compare relatively
Millisecond timings are only meaningful on a specific hardware target.
Not sure when you read this, but I can tell you that two years ago it was VERY slow. I used it for a game and I had to redo it in lua some months later because it was a big bottleneck. I don't have more up to date information.
In an Apollo GraphQL federation, you can use Rhai to customize the Apollo Router's behaviour. The Apollo Router is written in Rust.
What does "Passes Miri." mean? There is no link and online I only find a Malaysian city with that name.
Someone else already answered, just a tip for future searches: If you know somewhat the context (in this case Rust), adding just one keyword to your query (in this case "Miri Rust") will give you the right answer as the first hit :)
Miri is a Rust tool with a similar function to Valgrind, it checks for undefined behavior.
For anyone curious for more details, miri works in a different way than valgrind. it is an interpreter for rust that does additional checks at runtime to detect undefined behavior. This allows it to be fully deterministic, simulate other platforms, and do additional checks that I don’t think would be possible for valgrind
Very impressive. I read the readme and I’m unsure how memory management works, is it GC? And is it OOP or not? Thanks :)
Only guessing, but since the language is for scripting then maybe all garbage could be collected when the script finishes?
I was also curious. Looking at the code, it seems values are Boxed, but there's a special type called Shared that is an Rc-RefCell (unless Send-enabled.):
// Also handle case where target is a `Dynamic` shared value
// (returned by a variable resolver, for example)
Couldn't find any other information about a GC, so guessing this is pure ref-counting. Speaking of potential memory leaks, there's also string interning happening. I agree this seems to be for short-lived contexts right now.How does it compare to Rune and the others?
That’s very cool! I appreciate how you can simplify interacting with rust applications without rust programming skills.
Cool! But wouldn't the way to go for scripting in a language these days to just compile to WASM and run in an embedded micro-VM? Why hasn't Rhai made this choice?
1. That require compiling to wasm, and for some use cases, you don't want a compilation step. That might even be a big part of why you are using a scripting language.
2. That requires an entire wasm runtime, which is a pretty heavy dependency
This is awesome. Would this be a replacement for Lua use cases in a Rust desktop app?
Needs a comparison to the excellent Rust Starlark Implementation.
Starlark is for config, not scripting.
I'm not sure what you think the difference is.
You can say that for everything, after all if it's turing complete you can do anything.
But practically, the difference is intention, which drives design and ecosystem.
E.g: starlark is very oriented toward idempotence and limiting side effects to get reproducible config data. By default they discourage reading files: https://github.com/bazelbuild/bazel/issues/13300
But rhai is not particularly oriented toward config, and the doc promotes an extension to read files: https://rhai.rs/book/lib/rhai-fs.html
The tutorials, stdlib, language design anf tooling will all reflect this.
You probably don't want to use starlark to automate much action, but it will be well suited to describe states.
IIRC starlark is intentionally NOT turing complete. It doesn't allow recursion, or general loops.
And rhai is, it allows infinite loops.