A solo Rust developer's runtime skips the interpreter entirely and proves correctness against CPython's own 244 module conformance floor, swapping per object reference counting (cleanup the moment the last reference dies) for a tracing garbage
A single Rust developer has published a GitHub project called pon that compiles Python 3.14 source files directly to native machine code, skipping the interpreter and the bytecode step entirely, and uses CPython's own test suite as the gate for whether a build counts as correct. The pipeline runs the ruff parser over the source, lowers the program into a shared intermediate representation, and hands that IR to Cranelift, the code generator that also powers Wasmtime. pon run exposes the result as an in-process JIT; pon build produces a standalone native executable ahead of time. (pon)
The repository commits two frozen files: a JIT conformance floor listing 244 Python modules that produce byte-identical output to CPython 3.14.0, and an AoT parity floor of 206 modules that also pass when compiled ahead of time. Correctness runs against a byte-exact differential harness using CPython 3.14.0 as the reference interpreter. That structure turns "matches CPython" from a slogan into a file two people can diff.
pon replaces CPython's reference counting with a tracing garbage collector the project calls Green Tea GC. Reference counting gives CPython deterministic cleanup the moment the last reference dies, which downstream libraries probe through __del__, weakref callbacks, and sys.getrefcount. A tracing collector defers cleanup into batches and shifts the timing. pon handles this with a divergence ledger that names the modules whose semantics legitimately diverge under tracing GC, capped at 25 entries, with every addition requiring maintainer approval. Three categories qualify: refcount observability, __del__ timing, and weakref timing.
The project's GitHub Actions pipeline has 63 workflow runs in total; run #62, on commit a086326, failed on a C-API fix for iterator slots and exception handling. Toolchain pins show the bet: nightly-2026-04-29 Rust, MSRV 1.94.0, ruff 0.14.0, cranelift 0.133.1, CPython v3.14.0 as the reference. The maintainer's public roadmap lists ≥5× CPython geomean speedup and ≥20× on numeric code as goals, not measured results, and the project ships no benchmark numbers against PyPy, Cinder, or CPython 3.14's own JIT.
The HN thread flags two specific concerns. Dynamic-typing JITs are hard: CPython itself has been chipping at the problem for years with specialization and inline caches, and serious prior attempts (PyPy, Cinder, Pyjion) all sit somewhere on the conformance-versus-throughput frontier. The solo-developer economic model is fragile too. A compiler project of this scope is the kind of work that normally takes a team of compiler engineers with corporate funding, and several commenters compared the project to Fable-style custom-target compilers, where the visible artifact looks small but the underlying work is years of accumulated edge cases.
Three things have to land for the headline claim to stop being a one-developer bet: a no-GIL build, the C-API gap that broke run #62, and the AoT floor climbing past 206 modules. The public CI is the first place any of that shows up.