6 ms·

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

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)

thayne 2y ago
> 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.
tel 2y ago
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.
- VWWHFSfQ 2y ago
  > 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.
  - azdle 2y ago
    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 https://github.com/kyren/piccolo)
  - tel 2y ago
    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.
- larusso 2y ago
  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.
noodletheworld 2y ago
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 https://github.com/moai/moai-dev [2] - ...and yes, I'm aware that moai is especially egregious in this regard. I get it.
- airstrike 2y ago
  "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.
- larusso 2y ago
  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.
diggan 2y ago
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/ 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 https://github.com/mattwparas/steel) looks like the most useful scripting environment for Rust currently.
- lionkor 2y ago
  mlua has serde support
  - diggan 2y ago
    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 :/
    - lionkor 2y ago
      I also learned the hard way that it has serde, similar to you :l
IshKebab 2y ago
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.
- VWWHFSfQ 2y ago
  > 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.
  - lolinder 2y ago
    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.
    - deleted 2y ago
      [deleted]
  - IshKebab 2y ago
    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. Take a look at the example code here: https://www.lua.org/pil/11.2.html https://www.lua.org/pil/11.2.html What index does the flattened `mt` start at?
ema 2y ago
Which features would compel you to use a language targeting roughly Lua's niche over Lua?
- cap11235 2y ago
  Thousands of devs vs some random lang
laerus 2y ago
The Rhai interpreter is configurable, you can choose which features of Rain will be available on the runtime. You can even disable keywords.
- cap11235 2y ago
  Just like lua?
perrygeo 2y ago
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 https://github.com/mattwparas/steel). Historically, Lua is the fun hobby project newcomer.

thayne 2y ago

> 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.

tel 2y ago

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.

VWWHFSfQ 2y ago
> 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.
- azdle 2y ago
  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 https://github.com/kyren/piccolo)
- tel 2y ago
  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.
larusso 2y ago
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.

noodletheworld 2y ago

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 https://github.com/moai/moai-dev [2] - ...and yes, I'm aware that moai is especially egregious in this regard. I get it.

airstrike 2y ago
"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.
larusso 2y ago
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.

diggan 2y ago

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/ 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 https://github.com/mattwparas/steel) looks like the most useful scripting environment for Rust currently.

lionkor 2y ago
mlua has serde support
- diggan 2y ago
  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 :/
  - lionkor 2y ago
    I also learned the hard way that it has serde, similar to you :l

IshKebab 2y ago

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.

VWWHFSfQ 2y ago
> 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.
- lolinder 2y ago
  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.
  - deleted 2y ago
    [deleted]
- IshKebab 2y ago
  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. Take a look at the example code here: https://www.lua.org/pil/11.2.html https://www.lua.org/pil/11.2.html What index does the flattened `mt` start at?

ema 2y ago

Which features would compel you to use a language targeting roughly Lua's niche over Lua?

cap11235 2y ago
Thousands of devs vs some random lang

laerus 2y ago

The Rhai interpreter is configurable, you can choose which features of Rain will be available on the runtime. You can even disable keywords.

cap11235 2y ago
Just like lua?

perrygeo 2y ago

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 https://github.com/mattwparas/steel). Historically, Lua is the fun hobby project newcomer.