Mica is a systems programming language as fast as C, with memory safety the compiler proves. 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. Where the compiler can’t follow a pointer it doesn’t guess: it tells you exactly what it couldn’t prove, and a checked build turns any residual mistake into a loud, source-located trap instead of silent corruption. The whole compiler is pure Go with zero external dependencies — no LLVM, no GCC backend — emitting native Linux x86_64 and ARM64 binaries with DWARF v5. Every stage is inspectable, and the compiler narrates the memory decisions it makes.

This is the public, maintained home for Mica’s long-form technical documentation, moved here from the compiler repository so the website is the canonical source.

Where to start

A Technical Portrait — the deep dive. A nine-chapter guided tour of the real compiler, from the language a programmer writes, through flow-proven heap safety and the SSA optimizing backend, down to the ELF binary and the debugger. Read in order for the full picture, or jump to the chapter whose subject you came for. This is the canonical technical reference.

The one-page Technical Summary — five minutes. Every major feature, and how each one stands against GCC 15. The fast way to judge whether Mica is worth your deeper attention.

Learning — for developers who want to start writing Mica. Tutorials and guided material, beginning with the basics of the language.

Reference glossaries

The core terms used across the project — language and type system, memory safety and the heap, the compilation pipeline, the backend, the platform, and the tooling — defined in one place, in three languages:

  • English — Glossary of Technical Terms
  • Deutsch — Glossar der Fachbegriffe (English–German)
  • 简体中文 — 术语表 (English–Chinese)

A note on accuracy

Mica is developed by a single engineer working with AI assistance, and this documentation is a living description of a project still in active development toward its 5.0.0 release. Specific names, API spellings, and feature boundaries change as the implementation reveals what actually works. Where a feature is designed but not yet fully wired, the text says so plainly — honesty about what is proven, what is implemented, and what is planned is part of the design.