Content about #Mruby

In Kobako: Exchanging Memory in WebAssembly we solved the problem of Ruby and WebAssembly interacting, and gave Ruby and mruby the ability to exchange values with each other, which basically cleared up the “sandbox” problem.

Kobako’s development is still at a very early stage, though, because there are plenty of problems that only show up in real use, and one of them is the problem of “deciding how to stop.”

The past few posts covered how MessagePack was chosen, but interacting through WebAssembly works a little differently from interacting with a native extension.

The reason is that what we’re building is a sandbox to isolate untrusted code, which means the operations are essentially close to one-directional. Code running inside the sandbox cannot touch any of the host’s memory, so the method calls we originally had in mind need some special handling.

Last weekend at COSCUP I gave a talk, “Let AI Take Over Your Application: Building a Seamless, Microsecond-Scale Ruby Sandbox,” covering some of the considerations behind Kobako’s design. During the Q&A afterwards, someone asked: in an era where AI makes the language matter less, why pick Ruby?

The short answer is simply “I like writing Ruby.” But there are much deeper considerations in how Kobako is designed.

Choosing mruby as the sandbox language came out of ruby.wasm’s limitations, but sharing the same language standard (ISO/IEC 30170:2012) with CRuby doesn’t mean the goal comes easily. Compared to CRuby, mruby comes with plenty of restrictions.

Those are the trade-offs mruby has to make to run in environments like embedded systems, and the lightweight nature that comes with them happens to be an advantage for an Embedded Sandbox. It turns the idea of embedding a Ruby sandbox into any language into a viable option.

mruby compiles source code using a compiler (usually mrbc), resulting in a binary file in the mrb format. This file format is called RITE, and in order to execute compiled mruby code, it needs to be parsed and read.