--- title: "Kobako: Why Ruby, After My COSCUP 2026 Talk" date: 2026-08-12T00:00:00+08:00 publishDate: 2026-08-12T00:00:00+08:00 lastmod: 2026-08-10T21:13:40+08:00 tags: ["LLM","AI","Experience","Ruby","WebAssembly","Gem","mruby"] series: "kobako" toc: true aiTranslated: true permalink: "https://blog.aotoki.me/en/posts/2026/08/12/kobako-why-ruby-after-coscup-2026/" language: "en" --- Last weekend at COSCUP I gave a talk, "[Let AI Take Over Your Application: Building a Seamless, Microsecond-Scale Ruby Sandbox](https://coscup.org/2026/session/KZ9PTY)," covering some of the considerations behind [Kobako](https://github.com/elct9620/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. ## Experimental{#experimental} Kobako came about because Harness Engineering got hot in early 2026, and combined with what I had experienced in late 2025, I had a few predictions about where things were heading. Broadly, I judged Virtual Filesystems and sandbox technology to be the most worthwhile bets. At RubyKaigi in April I brought these directions up with quite a few people, and then asked myself: why not give it a try? Being assigned to the dRuby group at RubyKaigi's Code Party pushed me further toward thinking a sandbox really was achievable: it was a matter of assembling existing pieces rather than designing a whole new solution. In the end, WASIp1's standard left me unable to extend ruby.wasm at all and locked down several key steps. But all of that became the foundation for Kobako's later design: driving the WebAssembly environment with the same Wasmtime, and designing the Host and Guest interaction in a way similar to dRuby. That is also what let my later proof of concept come together. ## Open Standards{#open-standard} Throughout the actual development I kept thinking about "degrees of freedom": whether the people using it can take it and do what they want with it. That matters a lot to me personally. I got lucky here. The Ruby ecosystem has mruby with nearly identical syntax, Wasmtime is Rust-based to begin with, and after the Ruby community spent the past few years pushing support for writing extensions in Rust, I really only had to think about how to design Kobako itself. Initially, my thinking was that WebAssembly itself is replaceable, so when designing the ABI (Application Binary Interface) I narrowed it down as much as possible to the combination most languages can use, and handled the default communication protocol with MessagePack. That means you can use any language that compiles to WebAssembly, not just mruby, so it is Ruby plus any language rather than mruby alone. Cleaning things up afterwards, I started thinking about a lot of public interface design questions. This happened to come from a friend whose company works on WasmEdge, essentially an alternative to Wasmtime, so I quickly introduced the `Runtime` concept: implement that trait, and any package capable of running WebAssembly can drive Kobako's architecture. Going further, to decouple things I added a lot of new interface designs, constantly asking "can this part be replaced?" Questions like "can MessagePack be swapped out?" or "if you don't need a dynamic interface, could you switch to Protobuf?" pushed the design further, step by step. So far, Kobako is more like a proposal for a general interface. You can use Rust to replace or extend the mruby running underneath, and you can swap out MessagePack or Wasmtime, which makes it feel like a framework rather than just a Ruby Gem. ## What Open Source Means{#meaning-of-open-source} Right before COSCUP, the character of the Kobako project and the shifts of the AI era led me to reconsider what "open source" actually is. Ever since open source became a hot topic, plenty of companies have used the open source banner to promote their own products. In recent years we have even seen many companies pull their open source licenses outright, or ship something that is not open source at all, closer to Source Available (just publishing the code). In other words, a lot of the projects we see online or on GitHub probably cannot be freely modified or reproduced. Is "open source" still the right word for that? This is exactly why people in the open source community treat so-called "open source models" as closer to "open weight models": those models only publish code, but nobody can modify them or reproduce them easily. All in all, open source to me feels more like "you are welcome to reshape this into whatever works for you." That is genuinely what I am thinking, subconsciously, when I put a project on GitHub. If it is just a small tool I find handy, I won't put much effort into it. For something like Kobako, I think very carefully about what the public interfaces look like and how users can customize them. Just providing that saves users a lot of time. That is basically why Kobako chose Ruby. It is a personal preference, sure, but every consideration behind it was designed to not be limited to Ruby.