p4lindromica

The mruby VM as used in Artichoke uses Artichoke's Rust implementations of `String`, `Symbol`, and `Array` (and many other core classes, these ones just happen to be used by the VM itself). The symbol table (which is an essential part of how classes and methods and `send` are implemented) is implemented using the `intaglio` crate which is part of the Artichoke project.

These implemented-in-Rust bits expose themselves to the remaining C with `extern "C"` APIs written in Rust that maintain ABI compat with the mruby code they replace.

The mruby VM is getting eaten by the Rust parts, so I don't think it's quite fair to say that Artichoke uses mruby as an off the shelf component. To fully move beyond mruby though to a native Rust VM will take time.

The compiler does have a lint to force being explicit about unsafe in the way you describe. It is an allow by default lint called `unsafe_op_in_unsafe_fn`.

Code size in an embedded context is one use case for the modularity here. Another is limiting access of Ruby code to the host system.

For example, one may wish to use Artichoke in a game engine for scene scripting. It’s probably undesirable for Ruby code run in this context to modify the host environment, so `ENV` can be disabled at compile time. But maybe you have existing code that uses `ENV`. Toggle a compile time flag and you can get a compatible `ENV` implementation that is backed by a hash map.