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.
Small comment, but why does the text editor show an "overwrite" indictor instead of a cursor indicator when I try to change something in the playground? https://i.imgur.com/OAXbXQ2.png
I tried typing different things, and despite showing an overwrite indicator it seems to be in a normal insert mode. I have no idea which side of the highlight my characters will be inserted on though.
1. This is much easier to embed in Rust projects than Lua.
2. Doesn't make the mistake of 1-based indexing.
3. Generally much more modern and nicer language than Lua.
The reasons I've found not to use it:
1. Very slow - even slower than Python! Of course often this won't matter but it would be nice if it was fast.
2. No support for type annotations.
I've used it before for a config file, and it worked well there. I think if I wanted anything much more complex though I would just embed V8. Then you get a language that everyone already knows and very good type annotations.
I don't think "ecosystem" really matters much for embeddable languages like this. You app is the ecosystem.
Is there something in specific that makes this easier to use in Rust projects compared to the Lua wrappers/bindings like mlua[0]? Or is it just an overall ergonomics thing?
Genuine question, as I don't have any prior experience embedding any scripting language into a Rust project.
> By default mlua uses pkg-config tool to find lua includes and libraries for the chosen Lua version. In most cases it works as desired, although sometimes could be more preferable to use a custom lua library.
The fact that Rhai builds with just 'cargo build' shouldn't be underestimated - a Rust project with all pure-Rust dependencies is much easier to maintain / support / distribute across a wide variety of hosts!
Then mlua will statically build with the Lua sources it bundles itself and no need to link the system Lua or do anything other than "cargo build" like normal.
Zig is first and foremost a C compiler with cross-compilation being first class citizen so you can't really compare the two.
> Rather than developing and increasingly insular (navel-gazing?) ecosystem, it might be better to work on the root problem.
Every language has its own development budget and must focus on what makes more sense. Zig has great cross-compiling story and C is first class, Rust has a stable language, a compiler that doesn't crash and emits readable error messages, one has to set its priorities.
The good thing with zig is that you can use the zig compiler within Rust project to cross-compile C code (cargo-zigbuild IIRC) so you can have a cake and eat it too.
This is a very uninformed take. It's not a Cargo or Go problem, it's a C problem. It only works well with Zig because Zig goes to insane lengths to hide the problem.
In fact it's so much of a C problem that lots of people even cross-compile their pure C code with Zig, because Zig handles all of the C mess!
Perhaps instead the more constructive path would have been to try and defend why one (cargo, rust) cannot do what another (zig) can.
So far, all I can infer is an acceptance of how compiling C code is hard and rather messy. I am no more uninformed on this than this literally being a daily fact of my paid life, but do go on, tell me how I've missed the point.
The condescending tone started with you calling projects "deficient" for not handling problems well they don't want to handle. Yes, a C compiler is good at C things. It's not "deficient" if that C compiler sucks at integrating BASIC code.
Yes, it is designed for Rust, so the actual interop with Rust is very good. You can pass Rust types in and out with very little work, and they are represented in Rhai in a logical way.
Even something like a `Vec<u64>` is likely to be a right pain with Lua.
My frame: I would say that embedding in rust is hard, unless you are already thinking in rust. Mostly ownership things, which I see distinct from safety.
If you are thinking in rust already, why would you go to an FFI c solution?
(Source: have been prototyping DSLs in rust with most of my life force for about a year)
An interesting thing about bikesheds is that sometimes they become bikefortresses: if 99% of the world (including the surrounding userbase, in the case of Rust) expects 0-based indexing, then the choice of something that uses 1-based indexing is harder to justify.
This doesn't make one better than the other, but precedent/familiarity does matter and represents a valid decision weight.
I don't particularly disagree. Although it's worth noting that people don't typically pick embedded languages because they're familiar with the embedded language per se, but instead because they (1) are easy to integrate, and (2) resemble the syntax/semantics of the embedding language. Rhai appears to satisfy both, so I can understand why someone would pick it.
(I don't have a dog in this fight; I'm not a user of either Lua or Rhai.)
No one can convince me thst 0-based indexing is worth more than widespread editor syntax -highlighting support, working LSPs, lots of blog posts, books and more vs a new niche language whose marquee feature seems to be it is easier to embed in rust.
Again, I don't want to put down the authors, making languages and tooling is fun and awesome, but I wouldn't pretend this is a rstional replacement for Lua.
It's absolutely a valid and serious answer? You asked for reasons, omitting two options, and they gave you a list of points for and against not including those two options. That's a good response, you don't need to agree with it, but I don't see how you can call it not serious?
The answer as a whole is serious, I said as much, read again.
A singled out this one point, because it is not.
It is akin to any other knee-jerk dismissive attitude to anything different.
Casting away a far more proven language, used for over a decade in thousands of serious, commercial projects with wide editor (and LSP) support etc over indexing conventions, is not serious.
Lua is my first 1-indexed language, i have yet to have a single bug over this. It's a irrational fear.
But a vague, unsubstantiated feeling that one day, you might introduce a one-off indexing bug should not justify discarding Lua, and all its substantial benefits over project.
Arguing the pro's of Rust data-structure interop in case of a Rust project - that makes sense. This, this is basically nonsense.
> But a vague, unsubstantiated feeling that one day, you might introduce a one-off indexing bug should not justify discarding Lua, and all its substantial benefits over project.
Nobody said anything like that. There's no vague feeling of indexing bugs; there's a concrete degradation of code quality.
And yes it's only one factor, not a deal-breaker. Nobody here said it was.
I never said 0-based indexing was sufficient to choose it over Lua on its own. Just that it is an advantage over Lua, which it is.
Also I don't think Lua's LSP/type annotations are anything to boast about. They exist, but they aren't good. If you care about that there are way better choices - Typescript, or maybe Dart (not sure how embeddable that is though).
A lot of people would call this a feature, not a mistake. 0-based indexing came from programming languages typically calculating addresses in the memory layout of an array. Whereas in mathematics (the background of the Lua inventor) sequence positions typically start at 1. Also, humans generally start counting from 1. This is intuitive in languages like SQL which also use 1-based indexing.
It could be argued that 0-based indexing was the mistake since it actually conflates two concepts, the memory layout in the machine, and the actual sequence you want to index.
Those people are wrong. Maths is wrong too but it doesn't matter so much for maths because you can hand wave syntax to do whatever you want. Guess what style of indexing formal mathematical proof systems use...
Fundamentally either work, but 1-based indexing is a mistake mainly because it leads to much less elegant code.
A simple example is accessing rows in a flattened matrix (or 2D array).
With 0-based intervals and right-open intervals it is
array[stride*y .. stride*y + width]
With 1-based it is
array[stride*(y-1)+1 .. stride*(y-1)+1+width]
Ouch. Code dealing with intervals is simpler with 0-based indexing & right-open intervals 99.9% of the time.
I think you're still conflating two different concepts, but this is mostly natural at this point since I assume you program in languages that use 0-based indexing. 1-based indexing focuses on the conceptual sequence rather than the underlying implementation details. Even your matrix flattening example is conflating concepts, although that's "normal" at this point. 0-based indexing certainly lends itself nicely to interval arithmetic, I agree.
> What index does the flattened `mt` start at?
I'm not sure if I missed a point you were getting at with this? Lua array table indexes start at 1.
My first boss who started in the late 60's said 1 based indexing exists because the early programmers with mathematics training thought ordinary people are too stupid to get zero based indexing.
Yeah I think that's the only plausible reason. Quite patronising but I think it probably came from an honest "make programming more accessible to non-programmers" place. They just forgot that the rest of programming exists...
You see that in books and papers and tutorials a lot. They'll explain some basic concepts nicely and then realise that they can't really explain ELI5 calculus and skip straight into Laplace transforms.
I once read a highly technical manual for a SystemVerilog simulator that began by explaining what double-clicking was. No joke. That's basically 1-based indexing.
I agree that it's wrong to label Lua's choice a mistake—when it was created in 1993 there wasn't as overwhelming a consensus in favor of zero-based indexing as there is now. But now the consensus is there, so whether it's a mistake or not it's not worth fighting against. Programmers today learn zero-based indexing and trying to get someone who's used to that to adapt to one-based indexing is not trivial.
>It could be argued that 0-based indexing was the mistake since it actually conflates two concepts, the memory layout in the machine, and the actual sequence you want to index.
This could be argued to be a feature. That it isn't conflating the concepts but communicating both.
> 2. Doesn't make the mistake of 1-based indexing.
Why is this a mistake? I've used 0-based languages primarily, but ergonomically, 1-based languages like Awk and Smalltalk are fine too, making some code slightly harder to write and other code slightly easier. Overall, I've found it to be a wash. If anything, in a pointer-less language, pedagogically, 1-based is more intuitive for novices.
P.S. Classic VB and VBA had an odd feature where one could choose the base for themselves, using the Option Base feature.
It's interesting that merely asking someone to explain their justifications for something, without even outright criticizing it or Rust itself, is enough to net downvotes in Rust threads.
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.
You're right, thanks! I did a quick grep with "serde" on the features exposed by `mlua` before posting that comment, but of course they named the feature "serialize", so didn't show up :/
Thanks for these examples. I wrote a POC tool to apply common patches to multiple projects. These patches where supposed to be written as scripts. Idea was to run the same set of action on projects with different layouts based on their names etc. So a normal patch would not work.
Anyways I used mlua because it was the easiest way to get some scripting to run. But I faced issues writing the scripts. Basic operations had to come from the host like “string endsWith”, “list contains” and some other basic methods (Can’t remember which ones it where in detail). That mixed with the fact that Lua is so different. I knew I could not give this to any other dev in my team without a lot of instructions how lua handles stuff differently. So it’s nice to know I have a potential new goto solution when facing this again. Especially the ability to dumb it down.
> 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
And then bringing it into Rust is simple like:
let lua = mlua::Lua();
Are your requirements more complicated than this that makes it not as easy? I've never had to mess around with linking the system Lua, or anything else. mlua just brings its own Lua distribution with the `vendored` feature.
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)
It’s been a minute since I used my mlua integration. I recall more packaging difficulty, investigating LuaJIT and Luau for a while. I had to make more decisions around my API, whether it was OO or a package, what libraries to allow. When introducing my domain types, there were more ways to fail and more subtle documentation to read and grok.
Nothing was hard, but Rhai was easier.
If I were to write a system in my embedded trading strategy language, if I cared about extensibility and composition, maybe Lua’s complexity would begin to pay its way. But I’m not, I just want simple, hot-reloadable logic to drive some fast Rust code.
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.
"Not C++ and not cmake" is right on the money. Also Rhai seems to be in its infancy. Despite its current limitations, there's an argument for supporting it early to see where this road will take us. Hopefully to a relatively fast and more feature rich scripting language and engine that fit snuggly into Rust projects, which would be fantastic.
Also played around with moai back in the days when Doublefine had their Kickstarter and choose it as the base framework. But I found it hard to make the jump between c++ and lua etc. The docs made the decision when to write what simple. Everything lua until it becomes a bottleneck. But when to start from nothing this decision is still hard. Pull a lib and expose it to Lua or try to write the lib in Lua? Stuff like that. I needed a basic triangulation algorithm for 2d shapes and implemented that myself from a paper about the ear clipping algorithm. Fun times. All hobby stuff just for fun and games.
For one, I don't like the Lua language. This is just my opinion but I dislike the syntax and semantics. It's better than vimscript for configuring neovim but that's a pretty low bar.
And if the argument is "pick a long-supported standard as an embedded language" then I'd rather go with Lisp (e.g. https://github.com/mattwparas/steel). Historically, Lua is the fun hobby project newcomer.
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?
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.
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
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.
I use it in rsmodules https://github.com/fretn/rsmodules and I’m very happy with my choice. Was easy to implement and the earliest versions already offered what I needed.
If the rhai author is reading this: thank you for this nice piece of software
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
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 :)
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
Have you ever seen how Starlark is used in the real world? The rulesets for Bazel and Buck could be described as "scripting". It quite literally automates actions.
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
Here are two real-world examples of using Rhai:
https://glicol.org/tour#meta1
https://glicol.org/tour#meta2
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:
https://koto.dev/
Other embedded scripting language is Steel [1]. It’s being considered to be used in Helix [2].
[1] https://github.com/mattwparas/steel
[2] https://github.com/helix-editor/helix/pull/8675
Another example using Rhai that was posted here a week or two ago: this (in-browser) 3D modeling software using Fidget.
https://www.mattkeeter.com/projects/fidget/demo/
> https://www.boringcactus.com/2020/09/16/survey-of-rust-embed...
For some reason, clicking on that link automatically downloads a file named "Human Fart.wav"...
Small comment, but why does the text editor show an "overwrite" indictor instead of a cursor indicator when I try to change something in the playground? https://i.imgur.com/OAXbXQ2.png
I tried typing different things, and despite showing an overwrite indicator it seems to be in a normal insert mode. I have no idea which side of the highlight my characters will be inserted on though.
This is totally my personal preference :)
I thought it was clearer this way.
But there is a new version of the website under construction:
https://glicol-x.netlify.app/
It will be changed to the normal look.
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)
1. This is much easier to embed in Rust projects than Lua.
2. Doesn't make the mistake of 1-based indexing.
3. Generally much more modern and nicer language than Lua.
The reasons I've found not to use it:
1. Very slow - even slower than Python! Of course often this won't matter but it would be nice if it was fast.
2. No support for type annotations.
I've used it before for a config file, and it worked well there. I think if I wanted anything much more complex though I would just embed V8. Then you get a language that everyone already knows and very good type annotations.
I don't think "ecosystem" really matters much for embeddable languages like this. You app is the ecosystem.
Is there something in specific that makes this easier to use in Rust projects compared to the Lua wrappers/bindings like mlua[0]? Or is it just an overall ergonomics thing?
Genuine question, as I don't have any prior experience embedding any scripting language into a Rust project.
[0]: https://github.com/mlua-rs/mlua
> By default mlua uses pkg-config tool to find lua includes and libraries for the chosen Lua version. In most cases it works as desired, although sometimes could be more preferable to use a custom lua library.
The fact that Rhai builds with just 'cargo build' shouldn't be underestimated - a Rust project with all pure-Rust dependencies is much easier to maintain / support / distribute across a wide variety of hosts!
This is just behind a feature flag like:
Then mlua will statically build with the Lua sources it bundles itself and no need to link the system Lua or do anything other than "cargo build" like normal.Still not as easy as pure Rust, e.g. for cross-compiling. It's similar to how pure Go projects are much easier to cross-compile than ones using cgo.
`cargo cross` exists, which can help but it's really a kludge.
This is a cargo deficiency then.
Zig has no problem using Lua (via the Ziglua wrapper) and cross-compilation is a single command away.
Rather than developing and increasingly insular (navel-gazing?) ecosystem, it might be better to work on the root problem.
Zig is first and foremost a C compiler with cross-compilation being first class citizen so you can't really compare the two.
> Rather than developing and increasingly insular (navel-gazing?) ecosystem, it might be better to work on the root problem.
Every language has its own development budget and must focus on what makes more sense. Zig has great cross-compiling story and C is first class, Rust has a stable language, a compiler that doesn't crash and emits readable error messages, one has to set its priorities.
The good thing with zig is that you can use the zig compiler within Rust project to cross-compile C code (cargo-zigbuild IIRC) so you can have a cake and eat it too.
This is a very uninformed take. It's not a Cargo or Go problem, it's a C problem. It only works well with Zig because Zig goes to insane lengths to hide the problem.
In fact it's so much of a C problem that lots of people even cross-compile their pure C code with Zig, because Zig handles all of the C mess!
You can educate yourself here: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
That is a very condescending tone.
Perhaps instead the more constructive path would have been to try and defend why one (cargo, rust) cannot do what another (zig) can.
So far, all I can infer is an acceptance of how compiling C code is hard and rather messy. I am no more uninformed on this than this literally being a daily fact of my paid life, but do go on, tell me how I've missed the point.
The condescending tone started with you calling projects "deficient" for not handling problems well they don't want to handle. Yes, a C compiler is good at C things. It's not "deficient" if that C compiler sucks at integrating BASIC code.
Yes, it is designed for Rust, so the actual interop with Rust is very good. You can pass Rust types in and out with very little work, and they are represented in Rhai in a logical way.
Even something like a `Vec<u64>` is likely to be a right pain with Lua.
My frame: I would say that embedding in rust is hard, unless you are already thinking in rust. Mostly ownership things, which I see distinct from safety.
If you are thinking in rust already, why would you go to an FFI c solution?
(Source: have been prototyping DSLs in rust with most of my life force for about a year)
"suffer" 1-indexing vs no LSP, no books, no test-of-time, no ecosystem, no type annotations, slower.
I don't mean to be overly harsh, but this is just not a valid/serious answer. The other reasons are fine. This is pure bike-shedding.
An interesting thing about bikesheds is that sometimes they become bikefortresses: if 99% of the world (including the surrounding userbase, in the case of Rust) expects 0-based indexing, then the choice of something that uses 1-based indexing is harder to justify.
This doesn't make one better than the other, but precedent/familiarity does matter and represents a valid decision weight.
Sure it is a valid weight. But the weight is a millionth of the weight of the cons that come with using a new unused language for embedding.
I don't particularly disagree. Although it's worth noting that people don't typically pick embedded languages because they're familiar with the embedded language per se, but instead because they (1) are easy to integrate, and (2) resemble the syntax/semantics of the embedding language. Rhai appears to satisfy both, so I can understand why someone would pick it.
(I don't have a dog in this fight; I'm not a user of either Lua or Rhai.)
Not in this case.
No one can convince me thst 0-based indexing is worth more than widespread editor syntax -highlighting support, working LSPs, lots of blog posts, books and more vs a new niche language whose marquee feature seems to be it is easier to embed in rust.
Again, I don't want to put down the authors, making languages and tooling is fun and awesome, but I wouldn't pretend this is a rstional replacement for Lua.
It's absolutely a valid and serious answer? You asked for reasons, omitting two options, and they gave you a list of points for and against not including those two options. That's a good response, you don't need to agree with it, but I don't see how you can call it not serious?
The answer as a whole is serious, I said as much, read again. A singled out this one point, because it is not. It is akin to any other knee-jerk dismissive attitude to anything different. Casting away a far more proven language, used for over a decade in thousands of serious, commercial projects with wide editor (and LSP) support etc over indexing conventions, is not serious.
Lua is my first 1-indexed language, i have yet to have a single bug over this. It's a irrational fear.
Nitpick: you haven’t found any bugs. That doesn’t mean they don’t exist.
Yes. So there may be a price to pay, one day.
But a vague, unsubstantiated feeling that one day, you might introduce a one-off indexing bug should not justify discarding Lua, and all its substantial benefits over project.
Arguing the pro's of Rust data-structure interop in case of a Rust project - that makes sense. This, this is basically nonsense.
> But a vague, unsubstantiated feeling that one day, you might introduce a one-off indexing bug should not justify discarding Lua, and all its substantial benefits over project.
Nobody said anything like that. There's no vague feeling of indexing bugs; there's a concrete degradation of code quality.
And yes it's only one factor, not a deal-breaker. Nobody here said it was.
> A singled out this one point, because it is not.
It absolutely is. I gave you concrete reasons. (Edit: actually in a sibling comment)
> i have yet to have a single bug over this.
I never said anything about bugs.
I never said 0-based indexing was sufficient to choose it over Lua on its own. Just that it is an advantage over Lua, which it is.
Also I don't think Lua's LSP/type annotations are anything to boast about. They exist, but they aren't good. If you care about that there are way better choices - Typescript, or maybe Dart (not sure how embeddable that is though).
> Doesn't make the mistake of 1-based indexing.
A lot of people would call this a feature, not a mistake. 0-based indexing came from programming languages typically calculating addresses in the memory layout of an array. Whereas in mathematics (the background of the Lua inventor) sequence positions typically start at 1. Also, humans generally start counting from 1. This is intuitive in languages like SQL which also use 1-based indexing.
It could be argued that 0-based indexing was the mistake since it actually conflates two concepts, the memory layout in the machine, and the actual sequence you want to index.
Those people are wrong. Maths is wrong too but it doesn't matter so much for maths because you can hand wave syntax to do whatever you want. Guess what style of indexing formal mathematical proof systems use...
Fundamentally either work, but 1-based indexing is a mistake mainly because it leads to much less elegant code.
A simple example is accessing rows in a flattened matrix (or 2D array).
With 0-based intervals and right-open intervals it is
With 1-based it is Ouch. Code dealing with intervals is simpler with 0-based indexing & right-open intervals 99.9% of the time.Take a look at the example code here:
https://www.lua.org/pil/11.2.html
What index does the flattened `mt` start at?
I think you're still conflating two different concepts, but this is mostly natural at this point since I assume you program in languages that use 0-based indexing. 1-based indexing focuses on the conceptual sequence rather than the underlying implementation details. Even your matrix flattening example is conflating concepts, although that's "normal" at this point. 0-based indexing certainly lends itself nicely to interval arithmetic, I agree.
> What index does the flattened `mt` start at?
I'm not sure if I missed a point you were getting at with this? Lua array table indexes start at 1.
My first boss who started in the late 60's said 1 based indexing exists because the early programmers with mathematics training thought ordinary people are too stupid to get zero based indexing.
Yeah I think that's the only plausible reason. Quite patronising but I think it probably came from an honest "make programming more accessible to non-programmers" place. They just forgot that the rest of programming exists...
You see that in books and papers and tutorials a lot. They'll explain some basic concepts nicely and then realise that they can't really explain ELI5 calculus and skip straight into Laplace transforms.
I once read a highly technical manual for a SystemVerilog simulator that began by explaining what double-clicking was. No joke. That's basically 1-based indexing.
> I'm not sure if I missed a point you were getting at with this? Lua array table indexes start at 1.
The code example is
What index do I use to access the first element in mt? It isn't 1!If this was written using 0-based indices then the answer would be zero.
I agree that it's wrong to label Lua's choice a mistake—when it was created in 1993 there wasn't as overwhelming a consensus in favor of zero-based indexing as there is now. But now the consensus is there, so whether it's a mistake or not it's not worth fighting against. Programmers today learn zero-based indexing and trying to get someone who's used to that to adapt to one-based indexing is not trivial.
Have you read EWD 831? https://www.cs.utexas.edu/~EWD/ewd08xx/EWD831.PDF
>It could be argued that 0-based indexing was the mistake since it actually conflates two concepts, the memory layout in the machine, and the actual sequence you want to index.
This could be argued to be a feature. That it isn't conflating the concepts but communicating both.
> 2. Doesn't make the mistake of 1-based indexing.
Why is this a mistake? I've used 0-based languages primarily, but ergonomically, 1-based languages like Awk and Smalltalk are fine too, making some code slightly harder to write and other code slightly easier. Overall, I've found it to be a wash. If anything, in a pointer-less language, pedagogically, 1-based is more intuitive for novices.
P.S. Classic VB and VBA had an odd feature where one could choose the base for themselves, using the Option Base feature.
It's interesting that merely asking someone to explain their justifications for something, without even outright criticizing it or Rust itself, is enough to net downvotes in Rust threads.
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.
mlua has serde support
You're right, thanks! I did a quick grep with "serde" on the features exposed by `mlua` before posting that comment, but of course they named the feature "serialize", so didn't show up :/
I also learned the hard way that it has serde, similar to you :l
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.
Thanks for these examples. I wrote a POC tool to apply common patches to multiple projects. These patches where supposed to be written as scripts. Idea was to run the same set of action on projects with different layouts based on their names etc. So a normal patch would not work.
Anyways I used mlua because it was the easiest way to get some scripting to run. But I faced issues writing the scripts. Basic operations had to come from the host like “string endsWith”, “list contains” and some other basic methods (Can’t remember which ones it where in detail). That mixed with the fact that Lua is so different. I knew I could not give this to any other dev in my team without a lot of instructions how lua handles stuff differently. So it’s nice to know I have a potential new goto solution when facing this again. Especially the ability to dumb it down.
> 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.
And then bringing it into Rust is simple like: Are your requirements more complicated than this that makes it not as easy? I've never had to mess around with linking the system Lua, or anything else. mlua just brings its own Lua distribution with the `vendored` feature.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)
It’s been a minute since I used my mlua integration. I recall more packaging difficulty, investigating LuaJIT and Luau for a while. I had to make more decisions around my API, whether it was OO or a package, what libraries to allow. When introducing my domain types, there were more ways to fail and more subtle documentation to read and grok.
Nothing was hard, but Rhai was easier.
If I were to write a system in my embedded trading strategy language, if I cared about extensibility and composition, maybe Lua’s complexity would begin to pay its way. But I’m not, I just want simple, hot-reloadable logic to drive some fast Rust code.
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.
"Not C++ and not cmake" is right on the money. Also Rhai seems to be in its infancy. Despite its current limitations, there's an argument for supporting it early to see where this road will take us. Hopefully to a relatively fast and more feature rich scripting language and engine that fit snuggly into Rust projects, which would be fantastic.
Also played around with moai back in the days when Doublefine had their Kickstarter and choose it as the base framework. But I found it hard to make the jump between c++ and lua etc. The docs made the decision when to write what simple. Everything lua until it becomes a bottleneck. But when to start from nothing this decision is still hard. Pull a lib and expose it to Lua or try to write the lib in Lua? Stuff like that. I needed a basic triangulation algorithm for 2d shapes and implemented that myself from a paper about the ear clipping algorithm. Fun times. All hobby stuff just for fun and games.
For one, I don't like the Lua language. This is just my opinion but I dislike the syntax and semantics. It's better than vimscript for configuring neovim but that's a pretty low bar.
And if the argument is "pick a long-supported standard as an embedded language" then I'd rather go with Lisp (e.g. https://github.com/mattwparas/steel). Historically, Lua is the fun hobby project newcomer.
Which features would compel you to use a language targeting roughly Lua's niche over Lua?
Thousands of devs vs some random lang
> memory-safety can be assumed already to be understood, but not considered compelling arguments
Depending on your application, memory safety could be a very compelling argument.
The Rhai interpreter is configurable, you can choose which features of Rain will be available on the runtime. You can even disable keywords.
Just like lua?
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?
Since a quick ctrl-f didn’t find any mention here or on the README:
I assume the name is a reference to ChaiScript, which is a similar embedded scripting language for C++.
https://github.com/ChaiScript/ChaiScript
My understanding is that the creator of Rhai, Sophia Turner, is one of the original creators of ChaiScript, along with her cousin Jason Turner
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.):
Not even reference counting.
There are no references as values are always cloned (or moved).
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.
[1]: https://github.com/xNaCly/Sophia
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.
Writing scripts in rust is as easy as copying and pasting this shebang: https://neosmart.net/blog/self-compiling-rust-code/
But that doesn’t make it embeddable, of course.
Nightly doesn't need 3rd party tools at all: https://doc.rust-lang.org/cargo/reference/unstable.html#scri...
Technically my solution didn’t either. Does the nightly solution cache the output?
I use it in rsmodules https://github.com/fretn/rsmodules and I’m very happy with my choice. Was easy to implement and the earliest versions already offered what I needed.
If the rhai author is reading this: thank you for this nice piece of software
What does "Passes Miri." mean? There is no link and online I only find a Malaysian city with that name.
Miri is a Rust tool with a similar function to Valgrind, it checks for undefined behavior.
https://github.com/rust-lang/miri
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
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 :)
This is awesome. Would this be a replacement for Lua use cases in a Rust desktop app?
In an Apollo GraphQL federation, you can use Rhai to customize the Apollo Router's behaviour. The Apollo Router is written in Rust.
That’s very cool! I appreciate how you can simplify interacting with rust applications without rust programming skills.
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.
Have you ever seen how Starlark is used in the real world? The rulesets for Bazel and Buck could be described as "scripting". It quite literally automates actions.
Take a look here: https://github.com/facebook/buck2-prelude
Also, you are confusing how bazel uses starlark with starlark itself. It's trivial to expose an open or read_file function.
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
How does it compare to Rune and the others?