A Developer's Guide to Languages Designed Specifically for WebAssembly

As WebAssembly (WASM) continues to mature, a new wave of programming languages is emerging, designed from the ground up to leverage its unique strengths. A developer's search for the perfect WASM-native language for a retro-computing project provides a fascinating overview of the current landscape.

The project, hram.dev, aims to recreate the 80s/90s experience of booting up a new computer and programming it directly in assembly. To achieve this in a modern, sandboxed environment, the plan is to use WASM, offering users a choice between writing raw WASM Text Format (WAT) and a more convenient, higher-level language.

A Curated List of WASM-Native Languages

The search produced a comprehensive list of languages, each with a different approach to targeting WASM:

• AssemblyScript: A popular choice with a TypeScript-like syntax, Apache 2.0 license, and a minimal runtime with garbage collection.
• curlywas: A C-like, low-level language that seems complete and well-documented. Its simplicity and familiarity make it a strong contender.
• Onyx: A newer, actively developed language with OCaml-like features, powered by the Wasmer runtime, and featuring full documentation.
• Virgil: A language with a Ruby-like feel that includes a garbage collector and is under active development.
• wa: A Go-like language with thorough, though Mandarin-heavy, documentation.
• waforth: A Forth implementation for WASM, appealing to fans of stack-based languages.
• Walt: A JavaScript-like language that, while showing its age, was one of the earlier dedicated efforts in this space.

Key Considerations: Performance vs. Embeddability

One of the top recommendations for high-performance WASM development is Zig. It is renowned for producing extremely small, optimized WASM modules and includes WASM-specific built-ins, with a standard library that offers first-class support for the target. It can even optimize code for specific WASM runtimes.

However, a crucial requirement for the hram.dev project was the need for an embeddable compiler. The goal was to bundle the compiler directly into the application. Unfortunately, the Zig toolchain is not designed to be embedded as a library. The only alternative would be to bundle the zig executable and communicate with it via a subprocess, adding significant complexity (IPC, shared memory) that defeated the project's goals. This highlights a critical, practical consideration for developers: how the toolchain integrates into your project is as important as the language's features.

Ultimately, the C-like curlywas was favored for its balance. It was deemed not too low-level to be tedious, yet not so high-level as to abstract away the fun of close-to-the-metal programming. Its primary drawback was a lack of convenient memory access features like structs and arrays, a feature that could potentially be added, though its implementation in Rust presented a learning curve.