The official Rhai book is a pretty good introduction to Rhai. It’s one of a few language options that have targeted this “embed within Rust” area, and it does its job well!
I’m glad to see more embedded languages that are written in modern languages and are designed to properly interact with the host and share its safety guarantees.
Bringing a monolithic blob of C code like the PIC-Rio Lua interpreter into a Rust/OCaml/Haskell/etc. program is a rather terrible compromise no one should have to make.
Indeed. Because of this post I looked at rlua and mlua. Both projects complain about the difficulty of wrapping the Lua C API in Rust safely, in their READMEs. They’ve jumped through a lot of hoops to work around some behaviors.
I evaluated quite a few options for integrating Lua in OCaml programs and ended up resurrecting Lua-ML instead of using any PUC-Rio Lua bindings.
It still needs work because it only supports antiquated Lua 2.5 syntax, but the inherent type/memory safety and the ability to replace the standard library of the embedded language (completely or piecemeal) using functors made it feel like a worthwhile endeavor.
Hm how do they do this? What is the guarantee is exactly – if your language binding compiles then you won’t get an error at runtime? (definitely not true for Lua/C !! )
I’d be interested in some details about how the integration works. It looks like this hints at it:
Freely pass Rust values into a script as variables/constants via an external Scope - all clonable Rust types are supported; no need to implement any special trait. Or tap directly into the variable resolution process.
Related: the Lua authors wrote a great paper that talked about the mismatch between typing (dynamic vs. static) and memory management (manual vs. GC) as the core problem a C API needs to solve.
Off the top of my head based on some initial experiments with rlua/mlua, the main challenges they seem to have is how to avoid breaking the Rust side’s safety guarantees - i.e. basically how to make sure as many as possible of the Lua API functionalities are available without needing to mark funcs in the exposed Lua API unsafe. Especially when exposing Rust values and code to Lua, which is kind of the main point of embedding a scripting language. Based on that, purely speculating without looking at Rhai’s pitch at all, I would presume they might mean “just” this level of safety. Though I may be completely wrong.
The official Rhai book is a pretty good introduction to Rhai. It’s one of a few language options that have targeted this “embed within Rust” area, and it does its job well!
I’m glad to see more embedded languages that are written in modern languages and are designed to properly interact with the host and share its safety guarantees.
Bringing a monolithic blob of C code like the PIC-Rio Lua interpreter into a Rust/OCaml/Haskell/etc. program is a rather terrible compromise no one should have to make.
Indeed. Because of this post I looked at rlua and mlua. Both projects complain about the difficulty of wrapping the Lua C API in Rust safely, in their READMEs. They’ve jumped through a lot of hoops to work around some behaviors.
I evaluated quite a few options for integrating Lua in OCaml programs and ended up resurrecting Lua-ML instead of using any PUC-Rio Lua bindings.
It still needs work because it only supports antiquated Lua 2.5 syntax, but the inherent type/memory safety and the ability to replace the standard library of the embedded language (completely or piecemeal) using functors made it feel like a worthwhile endeavor.
Hm how do they do this? What is the guarantee is exactly – if your language binding compiles then you won’t get an error at runtime? (definitely not true for Lua/C !! )
I’d be interested in some details about how the integration works. It looks like this hints at it:
Related: the Lua authors wrote a great paper that talked about the mismatch between typing (dynamic vs. static) and memory management (manual vs. GC) as the core problem a C API needs to solve.
https://www.jucs.org/jucs_13_6/c_apis_in_extension/jucs_13_6_0839_0853_muhammad.html
Off the top of my head based on some initial experiments with rlua/mlua, the main challenges they seem to have is how to avoid breaking the Rust side’s safety guarantees - i.e. basically how to make sure as many as possible of the Lua API functionalities are available without needing to mark funcs in the exposed Lua API
unsafe. Especially when exposing Rust values and code to Lua, which is kind of the main point of embedding a scripting language. Based on that, purely speculating without looking at Rhai’s pitch at all, I would presume they might mean “just” this level of safety. Though I may be completely wrong.