Choosing a language

What the host requires

The host loads a WebAssembly component that implements one of two worlds (server-mod, client-mod) declared in host.wit. It does not inspect, and cannot tell, what produced the bytes. Nothing about Ironlark’s modding surface is Rust-specific by design: the contract is a WIT interface, and WIT exists precisely so that many languages can meet the same contract.

What currently narrows it

Every function in host.wit is an async function — including every function a mod must export. Implementing an async export needs component-model-async support in your language’s bindings generator, and that support is new. Rust’s wit-bindgen has it, and the reference mods use it.

This cascades rather than being a free choice: a mod has to await host calls like entity.spawn, and a synchronous export cannot await an asynchronous import. So async imports imply async exports, which implies a toolchain that can generate them.

So: Rust today, but not by design

Rust is what the reference mods use and the only path exercised end to end. It is not a design requirement, and “you must learn Rust to mod this” is not the intended answer.

Whether the host should also offer synchronous imports — so that Go, JavaScript, Python, C# or C toolchains without async component support can implement the world — is an open question, not a settled no. If you are here because you write one of those and cannot, that is useful to say out loud.

If you are trying another toolchain

The pieces you need are the same ones Rust uses:

1. host.wit — the contract. Vendor a copy; your generator reads it.
2. A bindings generator for your language that targets the component model (not classic wasm modules) and can emit async exports.
3. Output named <mod>_server.wasm / <mod>_client.wasm in the mod’s directory.

Step 2 is where you will find out whether your toolchain is ready. If it is, nothing else about the host stands in your way — and it is worth reporting, because it turns this page’s caveat into a list of supported languages.

What crosses the boundary

Payloads between mods, and between a mod’s halves, are bytes (list<u8>) — never language types. Pick your own encoding; the host neither parses nor cares. That is deliberate, and it is what keeps a mod written in one language usable by a mod written in another.

The same export, in each language

Rust

impl Guest for Component {
    fn init() { log(Level::Info, "hello from Rust"); }
    fn update(_dt: f32) {}
}

Go

func Init() { host.Log(host.LevelInfo, "hello from Go") }
func Update(dt float32) {}

JavaScript

export function init()   { log('info', 'hello from JavaScript') }
export function update(dt) {}

Пример показывает, как выглядят вкладки: syncKey держит все блоки на странице на одном языке, поэтому читатель выбирает один раз.