Ruby upgrade enhances WebAssembly support

An upcoming release of the Ruby language improves capabilities for WebAssembly, the highly touted binary format intended to improve web application performance.

Unveiled April 3, Ruby 3.2.0 Preview 1 offers an initial port of WASI-based (WebAssembly System Interface) WebAssembly support. This enables a CRuby binary to execute in web browsers, serverless edge environments, and other WASI embedders. WASI support encourages developers to utilize CRuby in a WebAssembly environment. An example use case is TryRuby playground’s CRuby support.

The Ruby 3.2.0 preview can be downloaded from the Ruby language website.

In elaborating on the WebAssembly backing, the developers of Ruby said that WebAssembly, or Wasm, originally was introduced to run programs safely and fast in browsers. But its objective—running programs efficiently with security in various environments—is sought not only by the web but by general applications. WASI is designed for such use cases. While many applications need to communicate with operating systems, WebAssembly runs on a virtual machine that did not have a system interface. WASI standardizes this interface.

Ruby’s developers cautioned that WASI and WebAssembly currently lack features to implement Fiber, exception, and garbage collection, due to continued evolution and security concerns. CRuby fills the gap by using Asyncify, a binary transformation technique used to control execution. Ruby’s developers also built a virtual file system layer on top of WASI to pack Ruby apps into a single .wasm file, making distribution of Ruby apps easier.

Ruby’s own WebAssembly efforts follow development of Wasmer Ruby, a WebAssembly runtime for Ruby based on Wasmer, which provides server-side capabilities for WebAssembly.

Ruby 3.2.0 also improves performance, moves the Find pattern out of the experimental stage, and introduces a timeout feature for Regexp matching. The timeout feature is intended as a security safeguard in cases where Regexp matching takes a long time. If code attempts to match a possibly inefficient Regexp against an untrusted input, an attacker may exploit it, resulting in a denial of service.