Questions about Miri

Miri is a statically typed, natively compiled programming language with first-class GPU programming built into the language rather than bolted on through a library. You mark data gpu to make it device-resident and launch a kernel with forall; the compiler infers every upload, launch and readback. Kernels compile to WGSL and run on Metal, Vulkan, DX12 and WebGPU; host code compiles to native machine code through Cranelift. There are no shader files, no FFI layer and no CUDA toolchain.

Three groups. AI and ML engineers writing custom kernels, who would rather express them as ordinary typed loops than as shader source handed to a runtime as a string. Graphics and GPU-compute programmers who want kernels, host code and data layout in one language and one type system. And compiler and language engineers, for whom the whole pipeline — lexer, parser, type checker, MIR, Cranelift and WGSL backends, standard library — sits readable in a single repository.

No. Miri is in beta and not production ready. The current release is v0.5.0-beta.3, and there are no prebuilt binaries yet — you install it by cloning the repository and building the compiler from source. Async and parallelism are unimplemented, WGSL/WebGPU is the only GPU backend, and Cranelift is the only CPU backend. Use it to explore the language, write kernels and file issues; do not put it under a production workload yet.

Working today: the CPU language — static typing with inference, value semantics with automatic reference counting, classes, traits, generics, closures, pattern matching, Option/Result, modules, a standard library and a test runner — plus the GPU preview: gpu residency, 1–3D forall, gpu fn kernels with shared memory, atomics and warp operations, vector types, and miri build --target web-gpu. Not there yet: async and parallelism, trait objects, capture-by-reference closures, native SPIR-V/PTX/Metal backends and an LLVM CPU backend.

Hand-written GPU code lives in a second language and a second build: shader or kernel sources, plus a host program that allocates buffers, copies data in, dispatches, and copies results back — with no type checking across that boundary. In Miri the kernel is ordinary code in the same file, checked by the same type checker against the same struct definitions. Residency is a property of a binding (gpu let), not a manual allocation, and the emitted WGSL is compiler output, not something you maintain.

Mark the data gpu so it becomes device-resident, then launch a loop over it with forall; the body of that loop is the kernel. A kernel you want to name, reuse or give shared memory and atomics to becomes a gpu fn. You never write an upload, a dispatch or a readback — the compiler infers each one from where values cross residency. The GPU programming guide starts from a first kernel and assumes no GPU background.

The compiler runs on macOS, Linux and Windows. Kernels compile to WGSL and execute through WebGPU, so any adapter reachable that way runs them — Metal on Apple hardware, Vulkan on Linux and Windows, DirectX 12 on Windows. No vendor SDK and no CUDA toolchain is involved, so the same kernel runs on AMD, Intel, Apple and NVIDIA hardware. Native SPIR-V, PTX and Metal backends are planned but not shipped.

Yes. miri build --target web-gpu compiles a Miri program into a self-contained WebGPU bundle that runs in any WebGPU-capable browser, with gpu frame inputs wired to real pointer events. It is the same source that runs natively — no separate web port. Every demo in the GPU Playground is such a bundle, compiled from the program shown next to it. 64-bit scalar types are unavailable in browser bundles.

No, and you never write a memory annotation either. Primitives and small all-primitive structs are copied bitwise; strings and collections are reference counted, with the IncRef and DecRef calls emitted by the compiler. A Perceus pass — precise reference counting, the technique Koka and Lean use — then proves which values are created, used once and discarded, and deletes their counter traffic outright, so idiomatic code compiles to straight-line allocation and drop. Assignment shares a buffer, the first mutation forks it, and use-after-move is a compile error.

For writing custom kernels, yes — that is one of the three audiences the language targets, and Tensor<T, Rank> in the standard library is the intended carrier for ML data reaching the device. It is not a training framework: there is no automatic differentiation, no optimizer library and no pretrained-model ecosystem, and cooperative-matrix (tensor core) instructions are unavailable until the native backends land. f16 is the smallest float today.

Miri is a standalone programming language with its own syntax, type system, standard library and compiler. It is not a library, a framework, an embedded DSL or a preprocessor hosted inside another language, and GPU kernels are not strings handed to a runtime — they are ordinary Miri code, type checked against the same definitions as the host code, that the compiler lowers to WGSL. Host code is lowered to native machine code through Cranelift.

There are no prebuilt binaries yet, so you build the compiler from source. Install the Rust toolchain, which the build needs, then git clone https://github.com/miri-lang/miri.git, cd miri and make build — the binary lands at target/debug/miri, or target/release/miri after make release. Add it to your PATH and run miri run hello.mi. The install guide has the full sequence.

Yes. Miri is released under the Apache License 2.0 and developed in the open at github.com/miri-lang/miri — compiler, standard library, test suite and the examples behind every demo on this site are all in that one repository. The issue tracker is where the roadmap is discussed, and each release records what changed.