Skip to main content
Nothing on this site documents a working production language. Mzizi is a Phase 0 prototype front end. Two small pilots of the benchmark ran on 2026-09-27, and neither showed an advantage for Mzizi (results). The run that tests the charter’s kill criterion has not happened. Only a service lowers to Rust, as a local Rust + axum package; no component lowers, and nothing renders. Mzizi has no expressions, bindings, callable functions, loops, error handling, modules or standard library yet: see what still has to be built.

​
Phase 0’s goal

Phase 0 has one goal: to build Mzizi as a programming language, measured against the best existing language for each kind of task (RFC-0009, and charter v0.4 §4). The languages it is measured against are TypeScript, Python, Go, C++ and Rust: Rust with Dioxus and Leptos and TypeScript with React for UI components, and TypeScript, Python, Go, C++ and Rust for backend handlers and services. Nothing has been measured against that yet. The two pilots below were the first tests inside Phase 0, on a few registry UI components against Dioxus. They are not its goal, and they showed no advantage. See the benchmark for every arm and whether it exists. The table below is the language’s front end, which lives in its toolchain, the mz compiler. The compiler implements the language; it is not the language. Checked against mzizi-dev/mzizi at 6da2170 on 4 October 2026. Every row below can be checked in the repository; that is why it is a table and not a paragraph. The language’s own list of what is missing, against Python, Go, C++, TypeScript and Rust, is LANGUAGE-TRACKER.md, summarised on What still has to be built.

​
What exists

The compiler source is 12,644 lines across compiler/src. The workspace has 425 tests in 18 suites, 294 of them in the compiler crate and the rest in the benchmark harness, runner and probe crate. CI gates on cargo fmt --check, cargo clippy --all-targets -D warnings, cargo test, mz check and mz contract over every primitive and example, and a lowering job that builds, tests and serves the example service. The compiler crate is version = "0.0.0" with publish = false. There is no cargo install mz, no published crate and no release. You build it from the repository or you do not have it.

​
What mz contract does, and what it does not

mz contract <file> evaluates a component’s own contract block against the component’s own declarations, and exits 1 if a clause does not hold. Across the nine primitives there are 29 clauses, and every one is evaluated. A variant row that leaves out height takes the height its h-N or size-N class renders, and a row whose height disagrees with its class fails mz check with MZ0313. It checks nothing rendered, and it does not compare a component with a reference implementation. That comparison is the other half of the Phase 0 defect metric, and it lives outside the compiler, in the benchmark harness. See the compiler and RFC-0006. For a service it runs the service in process instead: each example is one request, and each ensure is tested over a generated set of requests. examples/registry.mz has 22 clauses, tested over 61 requests. That is tested, not proven (RFC-0010 C-4).

​
The kill criterion

The rule is now RFC-0009 §6, the owner’s decision of 29 September 2026: Mzizi against the best existing language for each kind of task. Charter v0.4 §4 states it, superseding the Phase 0 criterion below. It has not been measured.
  • The kinds of task are RFC-0009’s gating families: ui-spec (UI components, against Dioxus, Leptos and React) and backend (handlers and services, against TypeScript, Python, Go, C++ and Rust).
  • Within each family, and for each metric, the bar is the best value any existing language reached. Mzizi passes the family when it beats that bar on at least two of the three metrics, on the headline ~7B model, on held-out tasks.
  • A win counts only if a paired bootstrap gives a 95% interval for the difference that excludes zero.
  • Phase 0 passes only when both families pass. A Mzizi service and its mzizi-be arm now exist, but no backend episode has run: the runner does not score with probes yet, and tasks B2–B5 and the other-language arms do not exist. Until they do, the backend family cannot pass.
As first written in the charter, the Phase 0 criterion compared Mzizi with raw Dioxus and Leptos on UI components only. That was a test, and it is superseded as the goal:
A defined benchmark where an LLM agent authors N equivalent components in Mzizi’s syntax vs. raw Dioxus/Leptos, measured on tokens consumed, iterations to a clean compile, and defect rate. If this doesn’t show a measurable advantage, nothing downstream matters — don’t build Phase 1 until Phase 0 has a real number attached to it.
RFC-0009 §6.3 argues the change is not moving the goalposts, because it only goes the harder way: beating the best on a metric implies beating Dioxus and Leptos on it. The gate itself is unchanged: Phase 1 waits for a real number. The two pilots are not that run. They used two or three public tasks, one comparison language and a checker that was still growing. Their honest reading is that they did not show an advantage. The second one found concrete fixes to make before the real run, and most of those are now made; see what remains. Every claim on this site about why a design decision is right is a stated rationale, not a measured result.

​
Results are always published

Every run lands in benchmarks/results/, whichever way it falls. That is an owner decision, not a courtesy. When the held-out task set exists, its scores will be published immediately and its task texts only when the set is retired.

​
What has been measured about the IR

From compiler/tests/ir_measured.rs, over the nine primitives and the two component examples. Services have no IR yet, so the example service is not in it. Eleven files is a tiny corpus, and the numbers should be read that way. The sharing figure is smaller than it was when the corpus had ten files, which is what a small corpus does. RFC-0003 §7 says the ratio should improve at registry scale, and labels that as a prediction until the registry is lowered.

​
Where the RFCs and the implementation disagree

Worth knowing before you copy an example out of an RFC and expect it to compile.
RFC-0001 and RFC-0002 both say “Status: draft for review — nothing here is implemented”. That was true when they were written. The front end now exists. Treat the headers as historical, and read the RFC index for each one’s current state.
RFC-0001 §1 writes view attributes without an equals sign, as in text state.label. The parser requires name = value, and every .mz file in the repository is written that way. Syntax documents the implemented form. A missing = is one MZ0406 on the line, with the = as its fix.
Every primitive sets portal = "https://mzizi.dev/components/<name>", pointing back at the registry entry for the component it ports. It is not in RFC-0001’s attribute list.
RFC-0003 §5 lists refs, path, patch and diff as next in implementation order. The binary dispatches check, fix, contract, outline and build, plus hash and ir for the IR. mz fix, which RFC-0001 §4.3 described, now exists. See the compiler.
RFC-0003 §4 shows a compact outline for button. The emitter in compiler/src/outline.rs lists variants one per line. The measured cost in §7 is from the real emitter; the printed sample is not.
Pilot 2’s write-up keeps a fuller table of places where the compiler and the RFCs disagree. See the pilot results.

​
The private repository does not exist yet

RFC-0004 specifies a private held-out benchmark repository, and then argues that it should not be created yet. A private runner that exists before the public harness does would shape the harness around itself. The trigger is stated: “the first held-out task. Not before.” The public half of the mechanism is in place and does nothing on purpose: .github/workflows/mzizi-lang-benchmark-dispatch.yml reports “not configured”, because the variable and secret it needs do not exist.