Ortus Solutions today announces MatchBox 0.12.0, the Rust runtime for BoxLang, alongside the launch of matchbox.boxlang.io: a new website with a live in-browser playground, a ten-lesson course, and complete online docs. The release also brings a more capable JIT, prebuilt native modules, a richer web runtime, and a long list of BoxLang compatibility fixes.

One platform, two runtimes

BoxLang is the software productivity platform for building, modernizing and running applications, with developers and AI agents working together. A platform like that has to run wherever your code needs to live, and one runtime can't reach everywhere.

That is why BoxLang now has two. BoxLang on the JVM gives you the full Java ecosystem, broad module coverage, and the infrastructure your applications already use. MatchBox, BoxLang on Rust, takes the same language to places a JVM does not fit: single binaries, the browser and edge, containers, serverless, and microcontrollers, with no JVM at runtime.

The two overlap where it makes sense and extend each other's reach where it doesn't. MatchBox does not replace the JVM runtime, it complements it. Write BoxLang once, then choose the runtime that fits where the code has to run. That wider surface area is what turns a language into a platform, and it is what makes BoxLang AI first. An agent that learns BoxLang once can target a server, a CLI tool, a browser tab, or a device.

MatchBox ships with 5 deployment targets, 4 JIT tiers, and 500+ compatibility tests transferred black-box from the BoxLang JVM suite. A hello world compiles to a ~4.8 MB native binary.

Deploy BoxLang everywhere

Pick the destination at build time. One codebase, many targets:

• Native: single self-contained executables for CLI tools, local applications and services. MatchBox compiles your BoxLang to bytecode and appends it to a stripped runner stub, so there is nothing to install on the destination.
• Browser and JS: client-side applications and libraries using WebAssembly and JavaScript integration, including Cloudflare Workers.
• WASI: containers and WebAssembly workloads outside the browser (experimental).
• AWS Lambda: serverless BoxLang (preview).
• ESP32: embedded applications with device-specific APIs and resource limits.
• Docker: a Linux multiarchitecture image, alongside eight full CLI binaries for supported platforms.

Targets share the language, not every capability, so we published the honest picture:

Test the artifact on the destination you plan to ship. The compatibility guide has the details. MatchBox is an independent, evolving implementation, and APIs and module support differ from the JVM runtime.

Native Fusion: BoxLang, Rust and Java in one loop

With MatchBox 0.12, we are putting the full weight of Rust behind BoxLang. Native Fusion is one of the biggest architectural additions the team has shipped to the platform. It links Rust functions and objects directly into your BoxLang application, on every MatchBox target: native, browser and JavaScript, WASI and ESP32.

Until now, the choice was familiar. You picked a productive dynamic language and accepted its limits, or you dropped into a systems language and rebuilt everything around it. Native Fusion removes that choice. You keep writing BoxLang for the application, and reach for Rust exactly where raw speed, a Rust crate, or low-level control matters. Same project, same build, one artifact.

Three directions, one runtime

• BoxLang to Rust: call native Rust from your BoxLang code as if it were any other function or object. Expose Rust functions as BoxLang BIFs and Rust structs as native objects, and BoxLang can use them like they were built in.
• Rust to BoxLang: it is a two-way street. Native code can call back into BoxLang functions through the same VM the built-in functions use, so Rust can take a BoxLang closure and run it.
• BoxLang to Java: native builds can reach Java classes over JNI. This is experimental and needs a JDK on the machine. It means a runtime built to run without a JVM can still reach into the Java world when you opt in. Java interop is not available in the browser.

BoxLang is the productive layer on top. Rust is the native engine underneath. Java is within reach when you need it. That is the BoxLang, Rust and Java ecosystem in one loop.

How it works

There is no glue project to maintain and no FFI plumbing to write by hand.

1. Create a native/ directory next to your .bxs entry script.
2. Write one or more .rs files inside it. Each file exports register_bifs() and/or register_classes().
3. Run matchbox --target native app.bxs.

MatchBox detects the native/ directory, generates a temporary Cargo project containing your Rust files, your bytecode and the VM, merges all BIF and class registrations, builds it with Cargo for the selected target, and writes the artifact. The result is a single hybrid binary that carries your BoxLang and your Rust together.

Native Fusion builds need Rust, the toolchain for your target, and the MatchBox source checkout used to build the CLI. Builds can run offline once you have cached your dependencies.

Macros that remove the boilerplate

The interop macros are re-exported from the matchbox_vm crate, so there is nothing extra to import.

• matchbox_fn turns a plain, typed Rust function into a BoxLang BIF. The macro generates the wrapper, validates the argument count, and coerces types for you. Supported parameter types are f64, i32, bool, String and BxValue.
• matchbox_class turns a Rust struct into a BoxLang native object by implementing the native object trait for you.
• matchbox_methods generates the method dispatcher, so BoxLang method calls land on the right Rust method. Method names match case-insensitively, just like you expect in BoxLang.

BoxLang instantiates native classes with new rust:<module>.<Class>(...), and BIFs are called like any other function. When you need full control, such as returning strings, null or objects, you can write a manual BIF against the low-level signature.

The whole Rust crate ecosystem, from BoxLang

Declare your dependencies in native/Cargo.toml and MatchBox merges them into the generated build. Relative path dependencies resolve against native/. That puts the Rust crate ecosystem within reach of your BoxLang application, from a hot path you want to run at native speed to a library BoxLang has never had.

One feature, every target

Native Fusion works on every MatchBox target, with one rule: your Rust code and its dependencies must support the target you choose. Browser builds cannot use desktop OS APIs. ESP32 code has to fit the device. WASI remains experimental. Use --target js for browsers and --target wasi for WASI hosts.

The same idea, native speed behind a BoxLang API, can ship to a server, a CLI tool, a browser tab, or a microcontroller.

Fusion and native modules

Reusable native functionality does not have to live in one project. In 0.12, MatchBox supports prebuilt native plugins packaged alongside shared BoxLang module code, so module authors can ship a familiar BoxLang API backed by native libraries. Native Fusion for your application, native modules for everyone else's, and a path to bring more of the BoxLang module ecosystem to MatchBox.

Know the limits

• Rust APIs and dependencies must match the target.
• matchbox_fn returns f64. Other return types need a manual BIF.
• BIF and class names must be unique across all files in native/.
• Java interop is experimental, native builds only, and needs a JDK.

Try it

Read the Native Fusion reference, then explore the course and the playground. Need Native Fusion modules, edge workloads or device firmware built to your brief? Talk to Ortus.

A new home: matchbox.boxlang.io

Try it live in your browser

The playground is a real MatchBox compiler and VM compiled to WebAssembly. No install, no JVM, no server. Your code runs on your device.

• A stateful REPL: the editor and console share variables, functions and objects.
• Six demos to start from: hello world, data pipelines, Fibonacci, objects with state, a Mandelbrot set, and the Game of Life.
• Share and embed: copy a link or embed snippet, with an optional read-only mode where viewers can run the code but not edit it.
• Honest limits: runs stop after 5 seconds, with 128 MiB of memory and 64 KiB limits on source and output. No files, network, DOM, JVM APIs or JIT. Sessions are not saved on reload.

Learn it in ten short lessons

The course takes you from your first script to a shipped native binary. Every code sample has a Run button that opens a live runtime right under it, so you can change the code and run it again.

Docs, complete and online

The documentation now covers Getting Started, Build and Deploy for every target, Web Development, and a full Reference: CLI, configuration, language, function reference, releases and downloads, compatibility, Native Fusion and the JIT. The docs are built with bxSites.

Built for agents too

Every docs page can be copied or viewed as Markdown, and the site publishes an llms.txt index and an MCP endpoint. Install the BoxLang skills with npx skills add ortus-boxlang/skills and your agent learns the targets, commands and limits. The Agentic Development guide covers giving an agent project context with AGENTS.md, keeping its feedback loop executable, and testing on the real target.

What's new in 0.12.0

More native execution, less busywork

The Cranelift JIT now compiles more real-world BoxLang patterns, including guarded array and struct reads, small record-returning helpers, binary-search loops, and append-only construction loops. JIT-enabled builds bring that capability to standalone desktop executables too.

In one targeted Linux experiment, 10,000 parser-token searches dropped from 254 ms to 87 ms, about 2.9x faster. That is a hot-path result, not a whole-application claim. Separate bx-lint measurements showed roughly 3 to 4% improvements in real-file edit medians.

Interpreted code gets faster too. Variable and member access do fewer repeated lookups, functions reuse cache buffers, identifier handling avoids unnecessary allocations, wide structs no longer need quadratic field-map copying, and positional native calls avoid scanning unrelated globals.

Native modules, ready to ship

MatchBox now supports prebuilt native plugins packaged alongside shared BoxLang module code. Module authors can ship platform-specific native libraries behind a familiar BoxLang API. Consumers can bundle those modules into bytecode applications or standalone native executables without Cargo or a JVM, and bundled applications carry their native artifacts instead of downloading them at startup.

The module runtime also gains annotated BIFs and member functions, custom components, interceptors, settings, mappings, and lifecycle hooks, a substantial foundation for bringing more of the BoxLang module ecosystem to MatchBox.

A bigger step toward native web applications

• Application.bx lifecycle hooks and live application state
• Application-isolated, in-memory sessions and cookies
• Request headers and bodies, redirects, and binary and file responses
• Multipart forms, native file uploads, and streaming static files

Installed modules stay loaded across requests, and bounded template caching reuses compiled programs while checking source contents so edits remain visible. This is still an experimental runtime. It is not full MiniServer parity and not a recommendation for internet-facing production deployments.

More BoxLang code works as expected

Template loops, switches and includes get important fixes. Classes gain working inherited initializers and super.method() calls, while property accessors, labeled loops, query-row iteration and destructuring rest assignments behave more like their BoxLang counterparts. Array callbacks preserve array semantics and receive the expected arguments, missing required arguments throw instead of silently receiving null, and waiting on a future inside a native callback no longer hangs.

New additions include SQLite datasources, encodeForHTML(), inline execution with --eval, and AST inspection APIs for language tooling.

Before you upgrade

• MatchBox CLI options now go before the script filename.
• Date and time formatting follows case-sensitive Java DateTimeFormatter patterns. MM is month, mm is minutes.
• For browser output, use --target js. --target wasm now produces the same WASI module as --target wasi.

Get started

Install MVM, the MatchBox Version Manager, then:

mvm install latest && mvm use latest
matchbox --version

The MVM installer scripts are on the quick start page. Not ready to install? Open the playground or take the course.

Need MatchBox in production?

Ortus Solutions offers priority support, architecture reviews, and custom development, including Native Fusion modules, edge and WASM workloads, and device firmware.

Resources

• Website: matchbox.boxlang.io
• Playground: matchbox.boxlang.io/playground
• Course: matchbox.boxlang.io/course
• Native Fusion: reference
• Agentic Development: guide
• Release: MatchBox 0.12.0
• Source: github.com/ortus-boxlang/matchbox
• BoxLang: boxlang.io | docs
• Community: Ortus Community Slack