JavaScript-friendly syntax
The language is designed to feel natural to JavaScript and TypeScript developers.
JavaScript-friendly syntax
The language is designed to feel natural to JavaScript and TypeScript developers.
Exact types
Types such as i32 carry defined width, signedness, and overflow behavior across targets.
One verified IR, three targets
The design requires every backend to consume the same verified Universal IR instead of translating through another target.
export function add(left: i32, right: i32): i32 { return left + right;}zryna build emits a direct ECMAScript module and zryna run invokes its exported scalar
function through strict i32 carriers.
The same verified IR emits an import-free core .wasm module directly. Browser bindings, WASI,
and Component Model profiles are not part of the current profiles.
Linux x86-64 builds lower through verified native MIR to a relocatable ELF object; run mode links and executes a dynamic ELF binary. Windows and macOS native execution are not claimed.
The intended source-to-artifact pipeline is:
.zry source ↓replaceable frontend provider ↓strict Zryna semantics ↓verified Universal IR ├── JavaScript backend → .js ├── WebAssembly backend → .wasm └── native MIR → codegen → executableRead the fixed M4 support matrix and
conformance boundary before selecting a mode.
The static matrix defines twelve rows and records not-evaluated; it does not itself
authenticate execution, installation, signed release, deployment or milestone closure.
Use the command sources, status example and denied/granted clock example. Installed components/browser/server, existing immutable beta H1, other browsers/platforms, general WASI authority, signed release authentication and production admission remain excluded. M0–M3 keep their existing profiles, bounds and manifests. The publication gate and milestone closure remain recorded in Issue #402.