This page is written for someone deciding whether Mica is worth an evaluation. It is not a scoreboard: C, C++, Rust and Go are all mature, well-engineered languages with ecosystems Mica does not have. What follows is where the design positions differ, including where the others are ahead.

Memory safety

MechanismAnnotationsRuntime costRejects correct programs?
Micaflow analysis, proven per allocationnonenone when provenno — ambiguity narrates instead
C / C++programmer disciplinenonenoneno
Rustownership and lifetimes in the type systemlifetimes where inference failsnonesometimes — the checker is conservative
Gogarbage collectionnoneGC pauses, throughputno

The distinguishing property is the failure mode. A borrow checker must be conservative inside the type system, so it will occasionally reject a program that is in fact correct, and the programmer’s job is to restructure until it is accepted. Mica’s analysis degrades instead: where flow escapes it, the site is reported rather than rejected, and the checked runtime floor catches anything that slips through. You are never arguing with the compiler about a program you know to be right.

The cost is a weaker guarantee. Rust proves more, statically, than Mica does. → Heap lifetime proof

Concurrency and data races

Data racesWhen you find out
Micarejected at compile timeat build
C / C++undefined behaviourin production, or never
Rustprevented by Send/Sync in the type systemat build
Godetected dynamically, if exercisedin CI, for interleavings a test happened to hit

Mica and Rust both give a build-time answer; they get there differently. Rust encodes it in the type system, which is powerful and general but shapes every API you write. Mica derives it from a marking discipline over the activation tree — one keyword at the point of shared access, and no ownership types in your signatures.

Go’s race detector is excellent at what it does, but it can only report races that actually occurred during a run. → Data-race freedom

Determinism

Same result across thread counts?Across architectures?
Micayes — bit-identical, by constructionyes, at a fixed optimization set
C / C++ with OpenMPno — reduction order variesnot guaranteed
Rust with Rayonno — reduction order variesnot guaranteed
Gononot guaranteed

This is the axis where Mica’s position is least common. Parallel numeric results are bit-identical to serial at every carrier count, because accumulations are never split — and the compiler’s own reductions stay on a single carrier rather than being offered fast with a caveat. If you have to certify a number, this is the difference between a regression test and a tolerance band. → Determinism

Calling C

MechanismError conventions
Micadirect, no wrapperlifted into the failure channel from a contract
C++directmanual
Rustunsafe plus a generated binding layermanual
Gocgo, with a call boundary costmanual

Everyone can call C; the difference is what arrives on your side of the call. In Mica, an imported C function is a failing function — the -1/NULL/errno convention is declared once in the contract and never appears in your code. Adoption is incremental: link one Mica module into an existing C program and debug both halves in one session. → The C boundary

Toolchain footprint

BackendExternal dependencies
Micaown, end to endnone, plus GNU as/ld
C / C++GCC or LLVMlarge
RustLLVMlarge
Goownnone

Go and Mica are the two with their own backends. For a procurement or supply-chain review, “the whole toolchain is ours, with no third-party code” is a materially different answer from an LLVM-based one.

Where the others are clearly ahead

Stated plainly, because you will find this out anyway:

  • Ecosystem. Rust’s crates, Go’s modules, and C’s decades of libraries are not comparable to what Mica has. The C boundary mitigates this considerably — you can use C libraries directly — but it is a real gap.
  • Optimizer maturity. gcc -O2 leads Mica on general code. Specific kernels reach or pass parity; broadly it does not.
  • Platform reach. Mica is Linux on two architectures. The others run essentially everywhere.
  • Tooling. Editor support is a VS Code extension; there is no language server yet. Debugging is good — real DWARF, real gdb — but the surrounding tooling is young.
  • Hiring and training. More people know the others.