Quickstart

The fastest path from a formalang source file to a runnable WebAssembly component is the bundled formawasm binary.

Compile a source file

Save this as id.fv:

#![allow(unused)]
fn main() {
pub fn id(x: I32) -> I32 { x }
}

Build the CLI and run it:

cargo build --release --bin formawasm
./target/release/formawasm id.fv
# wrote id.wasm (… bytes) from id.fv

By default the output filename is the input with .fv swapped for .wasm. Use -o <path> to override:

formawasm id.fv -o build/id.component.wasm

If the formalang frontend rejects the source, the diagnostic is printed in the upstream's standard format and the CLI exits non-zero. Backend errors print their typed Display form and also exit non-zero.

Inspect the WIT interface

The emitted .wasm is a Component-Model artifact. The standalone wasm-tools CLI prints the WIT interface formawasm generated:

wasm-tools component wit id.wasm

For the id example above, you should see:

package formawasm:generated;

world component {
  export id: func(x: s32) -> s32;
}

Every pub formalang function appears as a WIT export; every extern function appears as an import. Public structs and enums become record and variant declarations on a types interface — see Type Mapping.

Run the component

formawasm doesn't ship a runtime. The standard host-side library is wasmtime; the Hosting a Component chapter shows the full Rust-side wiring for instantiating a component, calling exports, and supplying host-provided imports.

What's next

  • Embed the backend directly in your build instead of shelling out to formawasmUsing the Library.
  • Understand exactly which formalang types and constructs the backend supports → Feature Coverage.
  • See the rules that govern what can cross the WIT boundary → Boundary Policy.