I keep thinking about DuskVM, the virtual machine Dusk uses for native smart contracts, and its choice of WebAssembly (WASM) as the execution format. WASM can be targeted by multiple programming languages, but Dusk's native contract workflow today is still largely built around Rust, from Cargo projects and contract templates to Forge tooling.

That creates a gap between what the runtime can technically execute and what developers can practically build with. What I don't know yet is whether DuskVM will become genuinely language-agnostic, or whether WASM mainly gives a Rust-first stack a portable execution format.

The mechanics worth watching are not how many languages can compile to WASM. They are which ones get first-class contract libraries, ABI support, testing and deployment tooling.

That distinction matters as Dusk builds infrastructure for regulated financial markets and native issuance. Runtime compatibility only tells me that the bytecode can execute. A complete developer workflow is harder evidence that another language is actually usable on Dusk.

I'd learn more from one non-Rust language reaching that level than from a long list of languages that can theoretically target WASM.

The question is whether Dusk is making language choice part of the developer experience, or only part of the runtime.

I am watching first-class non-Rust tooling next.

@Dusk $DUSK #dusk