What Mere Optimizes For

Every programming language is an answer to a question most languages never state out loud: what are we optimizing for? Speed of writing, speed of running, safety, simplicity, familiarity — you cannot maximize all of them, so a language is really a ranking. Most of the interesting differences between languages come from that ranking, not from syntax.

Mere’s ranking puts one thing on top:

The verifiability of correctness.

Not correctness itself — no language gives you that — but how easily you, or a tool, can check that a program does what it claims. Everything else in the design is negotiable in service of that.

Making the implicit explicit

The main lever for verifiability is a rule that sounds simple and turns out to touch almost everything:

Anything whose runtime representation or behavior can silently change is made explicit.

The word doing the work there is silently. Consider the things a typical language lets you not think about:

• Memory. Does this value live on the stack, in a heap allocation, in a garbage-collected object, in an arena that will be freed all at once? In most languages the answer is invisible at the use site, and it changes as the code evolves.
• Effects. Does this function read a file, mutate shared state, log, allocate? A plain T -> U signature says nothing. The effects are real, but they are ambient — carried in and out through channels the type never mentions.
• Sharing across threads. Can this value be handed to another thread? In most languages the type is silent, and the answer is “find out at runtime, or in a debugger.”

Each of these is a place where the program’s real behavior diverges from what its types tell you. Mere’s stance is to close those gaps: memory ownership, effects, and (as the series reaches concurrency) which values may cross a thread boundary all become things the type system talks about. You do not have to trust a comment or a convention; you read the signature.

The payoff is the whole point of the language: you can look at a piece of code and know what it does — what it touches, what it owns, what it might do behind your back — because there is no “behind your back.”

Why verbosity is an acceptable price

Making the implicit explicit has an obvious cost: there is more to write. A function that quietly logged and allocated now says so in its type. A value that lives in a region carries the region in its type. This is exactly the cost that pushes human-first languages the other way — toward inference, defaults, and ambient context — because a person has to type all of it.

Mere makes a different bet, and it is the bet that makes the whole design possible:

The code is written with AI assistance, so verbosity is cheap.

When “more to type” is no longer the binding constraint, the trade-off inverts. A language no longer has to hide ownership or effects to stay pleasant to write; it can surface them, because the friction of writing them out is largely gone. The thing that stays expensive — for humans and tools alike — is reasoning about a program you cannot see through. Mere spends verbosity to buy transparency.

This is not “more boilerplate is good.” It is: given that the code is co-written with a machine, spend the freed budget on things that make the program checkable, not on things that make it shorter.

Compromise is unavoidable — so choose where

A design that claims no trade-offs is hiding them. Optimizing for verifiability costs something real: some programs are more verbose, some patterns that lean on ambient state become awkward, and a few conveniences are given up on purpose. Mere’s rule is not to pretend otherwise but to name the trade-off each time and choose it deliberately.

Later episodes are largely a record of those choices:

• A region/view memory model instead of a garbage collector — explicit lifetimes, at the cost of more type structure.
• Capability passing for effects instead of ambient I/O — effects you can see in the signature, at the cost of threading capabilities through calls.
• Send / Sync for concurrency instead of “hope it’s fine” — data races ruled out by the type checker, at the cost of a couple more predicates.

In each case the compromise is stated where it is made, so a reader can judge whether Mere spent its budget well.

Not clever, not fast — legible

None of this is about being clever, and — despite what a project like this might invite — none of it is about being fast to build. The goal is narrower and, I think, more useful: a program you can trust by reading it. A signature that tells the truth. A type that changes when the behavior changes. A compiler that refuses the programs whose claims it cannot verify.

The rest of the series is this principle applied, piece by piece: a minimal core, then memory, then effects, then four backends, then the language compiling itself, then concurrency. Each part is the same question asked again — how do we make this checkable? — and the record of how it was answered.

Next: choosing a host language to build all of that in.