Content about #WebAssembly

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.

I’ve been working on Kobako for a few months now, and I’ll also be presenting the project at COSCUP. The process has been interesting enough that I think it deserves a series of posts about how I set out to build a sandbox for the AI era.

By the time of writing, there have been around 20 releases. From here on I’ll walk through Kobako’s evolution as close to chronological order as I can, along with the decisions made along the way.

Kobako is a sandbox I recently built on WebAssembly and mruby for the Ruby ecosystem, in support of Harness Engineering, to fill the gap where AI-written code has no safe environment to run in.

I already introduced Kobako’s design in a previous post, so this time I want to talk about performance. In its early versions, the Cold Start (the initial startup) took roughly 500 ms. That’s a lot slower than the 200 ms response time you’d usually aim for as a best practice. Even though AI generally tolerates slower responses, this isn’t about waiting on an LLM, so it still deserves to be judged by traditional API standards.