I began building Mica’s compiler in 2023, and for most of that time I kept it quiet. Not out of secrecy — the thing simply was not ready, and I would not put a claim into the world that the code could not back up. It is ready enough now to say plainly why it exists.

The reason

Mica is a systems language, as fast as C, with memory safety the compiler infers. Leaks, use-after-free, and double-free are build errors — caught by flow analysis, with no garbage collector, no borrow checker, and no lifetime annotations to write. The same machinery the backend already runs to schedule registers, I turned on lifetimes: every heap allocation creates an obligation the compiler must see discharged on every path through your function, and a path that would leak it does not compile. Use-after-free and double-free are rejected the same way, wherever the flow can prove them.

And here is the part I am most careful about, because it is the honest part. Where a pointer’s flow runs past what the analysis can follow — across a call, into an aggregate, through a cast — Mica does not guess and it does not pretend it proved something it didn’t. It tells you, in plain source order, exactly which allocations it could not prove, and a checked build turns any residual mistake into a loud, source-located trap instead of silent corruption. The boundary between proven and caught at runtime is something I measure, and it shrinks every release. That is the whole guarantee: conservatism may cost you a keyword now and then, but never a miscompilation, and never a rejected correct program.

I want to be equally clear about what this is not. The idea — memory safety without a GC and without a borrow checker, via flow analysis with a runtime backstop — is not mine and I will not pretend it is. It sits on a long lineage, from region calculus through Cyclone to Vale, Hylo, and Inko. People who know that field will recognize the shape immediately, and they should. What I claim is narrower and, I think, more defensible: of the languages exploring this design space, Mica is the one that actually ships it — a mature, fast, dual-architecture toolchain you can download and run today, where most of the others are still alpha, paused, or pre-1.0. The edge is execution, not invention.

The other reason: a compiler you can read — and reproduce

The second reason Mica exists is that I wanted a compiler a person could actually understand. Every stage is inspectable, from tokens through the typed intermediate language down to SSA, assembly, and ELF. The compiler narrates its own memory decisions, one line per allocation site, telling you the class it proved and the allocator it chose. Nothing about the safety story happens behind a curtain; you can watch it reason.

The whole thing is pure Go with zero external dependencies — no LLVM, no GCC backend. It emits assembly to the GNU assembler and linker, and a Mica binary links directly against any C library on the system, in both directions, with no wrapper. (That much is table stakes for a modern native language; what is rarer is that Mica’s safety analysis extends across the C boundary — disposing a foreign, C-owned pointer is a compile error — and you can step through Mica and C in a single debugger session.)

On speed I will only say what I have measured. Against gcc -O2, counting retired instructions with valgrind, Mandelbrot runs at 0.94× on x86-64 and 0.98× on ARM64 — below gcc’s instruction count on both — and a region-allocator workload that is allocation-bound runs at 0.80×. A hundred-thousand-line program compiles, fully optimized, in about five and a half seconds. Those are favorable numeric loops, not a claim that Mica beats gcc in general; gcc’s optimizer leads broadly and I am not going to suggest otherwise. To make sure no one has to take my word for any of it, a Docker container is coming so anyone can clone the repository and reproduce the gcc -O2 numbers on their own machine. Nothing to hide — that is the point.

The invitation

So this is not “the next big language.” It is a working result with an honest boundary, and I would rather show it to you than sell it to you.

What I am inviting is people to look, and then to build. If you work on programming languages, the memory-safety analysis — and the soundness argument behind it — is exactly the kind of thing that gets sharper under real scrutiny; I would far rather have skeptics as reviewers than as an audience. If you write C and have been told your only modern option is to rewrite everything in something else, Mica links into an existing C program one module at a time, so you can introduce a single proven-safe module into a live codebase and debug both halves in one session. And if you teach, or make things that explain hard ideas, a compiler that narrates its own reasoning is a rare thing to point a camera at.

I am one author. I set the vision and the architecture, I review and own every line, and I have been honest elsewhere about the fact that I build in close collaboration with AI — the tools serve the work, never the other way around. What I cannot do alone is everything that comes after a compiler exists: the scrutiny, the use, the teaching, the community of people who actually want to understand what their compiler is doing. That part I would like to build with you.

Come look. Clone it, break it, run the numbers yourself, and tell me where I am wrong. That is the whole invitation, and I mean every word of it.

— Michael Petersen, Mica Development UG