What Rhai Isn’t
Rhai’s purpose is to provide a dynamic layer over Rust code, in the same spirit of zero cost abstractions.
It doesn’t attempt to be a new language. For example:
No classes. Well, Rust doesn’t either. On the other hand…
No traits… so it is also not Rust. Do your Rusty stuff in Rust.
No structures/records/tuples – define your types in Rust instead; Rhai can seamlessly work with any Rust type that implements
There is a built-in object map type which is adequate for most uses.
It is also possible to simulate object-oriented programming (OOP) by storing function pointers or closures in object map properties, turning them into methods.
- No first-class functions – Code your functions in Rust instead, and register them with Rhai.
There is support for simple function pointers to allow runtime dispatch by function name.
No garbage collection – this should be expected, so…
No first-class closures – do your closure magic in Rust instead: turn a Rhai scripted function into a Rust closure.
There is support for simulated closures via currying a function pointer with captured shared variables.
- No formal language grammar – Rhai uses a hand-coded lexer, a hand-coded top-down recursive-descent parser for statements, and a hand-coded Pratt parser for expressions.
This lack of formalism allows the tokenizer and parser themselves to be exposed as services in order to support a wide range of user customizations, such as:
- disabling keywords and operators,
- dynamically changing tokens during parsing,
- adding custom operators,
- defining custom syntax,
- filtering variables definition.
- No bytecodes/JIT – Rhai uses a heavily-optimized AST-walking interpreter which is fast enough for most real-life scenarios.
See Rhai performance benchmarks.