Status

​

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 pilots below were tests inside Phase 0, on a few registry UI components, against Dioxus (pilots 1 and 2) and React (pilots 3 and 4). 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 2b36c8f on 29 October 2026, the merge of mzizi#140, which released staging to main and is tagged v0.12.0. The release of 20 October, mzizi#120, is 6f7b096, tagged v0.9.0; v0.11.0 (21 October) is ed5eab8. The release of 8 October, mzizi#109, is 1d5e578, tagged v0.8.0, the fourth of that day. The first, mzizi#91, is be88017, tagged v0.5.0; the second, mzizi#96, is dc156c5, tagged v0.6.0; the third, mzizi#104, is 4d0cdc3, tagged v0.7.0. 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 33,540 lines across compiler/src. The workspace has 765 tests in 29 suites, 634 of them in the compiler crate and the rest in the benchmark harness, runner and probe crate (the counts the language’s README states at 2b36c8f; the suite was not re-run for this update; the last full run, at 6f7b096, was 634 and 765, all passing). 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, runs every example program through mz run against its .expected output, and builds the performance suite and checks that its outputs agree. The compiler crate is version = "0.0.0" with publish = false. Each release of the repository to main is tagged (v0.4.0 is 0653903, v0.5.0 is be88017 and v0.6.0 is dc156c5, both of 8 October 2026, v0.7.0 is 4d0cdc3, the third release of that day, and v0.8.0 is 1d5e578, the fourth, and v0.9.0 is 6f7b096, of 20 October), but that tags the repository, not a published compiler: there is no cargo install mz and no published crate. You build it from the repository or you do not have it.

​

Released to main on 29 October 2026

The release of 29 October 2026 (mzizi#140, staging to main, merged as 2b36c8f and tagged v0.12.0) adds no language construct, and the language harness definition is unchanged (the same SHA-256 as at v0.9.0). What it carries, from the language’s CHANGELOG.md:

• A generated service can listen off loopback. mz build services read HOST (default 127.0.0.1) alongside PORT; a container sets HOST=0.0.0.0, and a value that is not an IP address stops the service with exit 1. Tracker row P11 says so.
• Generated services build slim. The generated Cargo.toml carries a [profile.release] (lto, codegen-units = 1, panic = "abort", strip, overflow-checks). The language’s changelog measured one example by hand (1,671,144 B to 934,720 B, idle RSS about 3.5 MB to about 1 MB). That is Rust’s output through Mzizi’s lowering, not a Mzizi advantage, and nothing here has met the kill criterion.
• The tokio pin moves to =1.53.3 in generated services, for RUSTSEC-2026-0386. Rebuild a service built before this.
• Pilots 3 and 4, published on the pilot results page.
• Merging is squash through the merge queue, in the language’s AGENTS.md, CONTRIBUTING.md and MIGRATION.md.

​

Released to main on 20 October 2026

The release of 20 October 2026 (mzizi#120, staging to main, merged as 6f7b096 and tagged v0.9.0) carries no new language construct. What it carries:

• The int minimum. -9223372036854775808 is read as a value only under a unary -, where it is i64::MIN and lowers to i64::MIN in Rust (RFC-0013 §3.1). Every other use of that literal is MZ0103. Tested in compiler/tests/program_numbers.rs.
• Two diagnostics adjusted. MZ0710 is not reported on a return whose declared return type the language cannot build yet; the one diagnostic is MZ0919 at the signature. MZ0962 names another language’s spelling as written (parseInt(s), toUpperCase), with the same fix. Tested in compiler/tests/program_collections.rs and program_text.rs.
• Tier 2, as a draft. RFC-0014 (mzizi#111) designs modules and imports across files (P1), the standard library (P2), lowering and runnable builds (P3, P4), errors mapped back to .mz (P5), and Rust crates through an exact pin (P6). Nothing in it is implemented: mz check does not accept import, module, public or extern today.
• Tests. 765 in the workspace, 29 suites, and 634 in the compiler crate, all passing. compiler/src is 33,540 lines. The language harness holds 197 entries: 79 distinct diagnostic codes (53 MZ09xx, 26 shared) and 49 pending codes. The 8 October page said 80 codes, with 27 shared; the definition does not give that, and the release added and removed no code entry.
• The CI and documentation fixes (#113 and #116, the rust-toolchain pins; #115, the README and the charter without a UI framework’s name; #119, the dated changelog).

Three build targets, decided on 2026-10-20 and not built. The owner decided that Mzizi builds to Cloudflare Workers (wasm32), containers (a standard OCI image, built with Docker by default and run by any OCI runtime) and bare metal (a native Linux binary), with every backend behind a trait and an adapter per side. The charter still says containers are reached from a Worker. RFC-0016 (a draft, mzizi#123) designs the three targets and is approved as design only (owner, 21 October 2026): the charter amendment and every build wave wait for the Phase 0 gate. The table above is unchanged: there is no Workers, Containers or WebAssembly target yet. Nothing here is measured against the kill criterion, and no benchmark has run on these features.

​

Released to main on 8 October 2026

The first release of 8 October 2026 (mzizi#91, staging to main, merged as be88017, tagged v0.5.0) carries the first work toward M1, a language that computes. Issue mzizi#69 tracks it, and the roadmap gives the plan. No pull request toward M1 is open on the language today.

​

The second release, the same day (mzizi#96)

The second release of 8 October 2026 (mzizi#96, staging to main, merged as dc156c5, tagged v0.6.0) moved the tracker’s marks. In LANGUAGE-TRACKER.md, C1, C2, C3, C4, C5, C9 and C10 are ✅, each with its “done when” checked on main. C6 (text operations) is 📝, and C7 (collections) and C8 (user types) are 🟡, so M1 is not reached. P4 and H1 stay 🟡: a general program cannot be written yet, and the plugin host is not built. The same release also:

• registers the four shared codes that a program’s enums raise and that were still pending, MZ0301, MZ0302, MZ0303 and MZ0704. The definition is now 137 entries and 70 codes, with 51 pending;
• corrects say texts that described C4 and C9 wrongly (MZ0919, MZ0902, MZ0921 and others), and adds a test that holds MZ0919’s list of unbuilt forms to the checker;
• takes the workspace to 644 tests, 513 of them in the compiler crate.

What still has to be built has the marks as the file now gives them.

​

The third release, the same day (mzizi#104)

The third release of 8 October 2026 (mzizi#104, staging to main, merged as 4d0cdc3 and tagged v0.7.0) carries the rest of the collections and records work and the text methods:

• Text methods (C6, mzizi#98). length, contains, starts_with, ends_with, trim, to_upper, to_lower, replace(old, by = new) and repeat(n). C6 stayed 🟡 until the fourth release: the methods that return an option or a list came with it. Programs: text methods.
• Collections (C7, mzizi#99). list(T), map(K, V) and set(K) in a program, with bracket literals, indexing that gives an option, otherwise, indexed assignment, in, for each over a list, range as a list, the methods, map, filter and the eight named folds. C7 is ✅. Programs: collections.
• Records and methods (C8, mzizi#101 and mzizi#102). Records with fields, fn methods, with and always invariants. C8 is ✅. Generics and interfaces are a new row, P12, deferred past M1 (RFC-0013 §20 Q21). Programs: records and methods.
• The language harness. Prefix not is listed at its real level, 8, which the checker and the parser already used (mzizi#100). The definition holds 191 entries, 80 diagnostic codes and 49 pending codes.
• Tests. 744 in the workspace, 613 of them in the compiler crate, all passing.

M1 was not reached after this release, while C6 was 🟡. Nothing here is measured, and no benchmark has run on these features.

​

The fourth release, the same day (mzizi#109)

The fourth release of 8 October 2026 (mzizi#109, staging to main, merged as 1d5e578 and tagged v0.8.0) carries the rest of the text operations (mzizi#106). With it, every Tier 1 row is ✅ on main:

• Text operations (C6, mzizi#106). s[i] and s.slice(a, to = b) return option(text), s.find(t) returns option(int), s.split(sep) and s.chars() return list(text), and s.parse_int() and s.parse_float() return option(int) and option(float). On 8 October 2026 the owner decided RFC-0013 §20 Q20: built-in methods with tests meet C6’s “Done when”. C6 is ✅, and Programs: text methods documents each method.
• Diagnostics. s.split("") is MZ0915, and an empty separator at run time traps (MZ0991, exit 101). t in s stays MZ0962, with the exact fix s.contains(t). No code is added.
• M1 is met on main. Every Tier 1 row, C1–C10, is ✅ in the tracker, so M1 (“all of Tier 1 ✅”, mzizi#69) is met. The public suites stay blocked, by the standard library (P2) alone. Generics and interfaces (P12) come after M1.
• Tests. 760 in the workspace, 629 of them in the compiler crate, all passing, as measured then. The language harness holds 197 entries, with 49 pending codes and 79 distinct diagnostic codes (this page said 80 then; see the 20 October section).

Nothing here is measured, and no benchmark has run on these features.

​

The performance suite is not a result

benchmarks/perf/ builds four foundation-slice programs (fib, ackermann, collatz and interpolate) three ways: lowered by mz build, and hand-written Rust built with overflow checks off and on. CI gates output agreement only: all three must print the committed .expected file. Timings are per machine, are not committed, and are never a claim; the suite is outside the kill criterion. Two sets of timings exist, each from a single 4-core virtual machine, and neither is committed to the language repository or tests the kill criterion:

• An informal fib(40) timing recorded on mzizi#69, about five noisy runs each: Rust’s release build took about 390 ms, Rust with overflow checks on about 690 ms, and the Rust the foundation slice lowers a Mzizi program to about 730 ms.
• One run of the suite, reported in mzizi#85’s description (median of 7 runs). The lowered Mzizi program took 0.97× to 1.45× the time of Rust with the same overflow checks (ackermann 0.97×, collatz 1.03×, fib 1.12×, interpolate 1.45×), and 1.43× to 5.67× the time of Rust’s default build, which does not check overflow.

In that run, Mzizi’s lowered programs were slower than Rust’s default build on every program, by up to 5.67×, and close to Rust with the same overflow checks on two of four programs and slower on the other two. No pass removes an overflow check yet.

​

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 four 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. 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.