Forem: Bryan MacLee

Null was a billion-dollar mistake. Falsy was the second.

Bryan MacLee — Sun, 19 Apr 2026 21:10:21 +0000

Null was a billion-dollar mistake. Falsy was the second.

"I call it my billion-dollar mistake. It was the invention of the null reference in 1965."
— Tony Hoare, 2009

Tony Hoare gets to call it a billion-dollar mistake because he invented null and watched the industry pay for it for forty years. Most of us inherited that mistake and added our own contributions on top. JavaScript, in particular, made two design choices in the 1990s that we are still paying for in 2026 and will keep paying for in any new codebase that ships tomorrow.

The first is having null and undefined as two distinct values for the same thing.

The second is "falsy."

I built scrml — a single-file, full-stack reactive web language — partly because I got tired of paying. The intro post is over here; this post is about the absence-and-truthiness fix that scrml makes possible because it is its own language with its own rules. It's also a rant, because some design decisions deserve one.

Mistake 1: two values for "no value"

JavaScript decided in 1995 that there should be both null and undefined. They mean almost the same thing. They are not interchangeable. They behave subtly differently across operators, methods, JSON, equality, and type coercion.

typeof null         // "object"     ← yes, really
typeof undefined    // "undefined"

null == undefined   // true   (loose equality treats them as the same)
null === undefined  // false  (strict equality does not)

JSON.stringify({a: null, b: undefined})
// '{"a":null}'      ← undefined is silently dropped

Where does each one come from? You can't predict it. null shows up wherever a developer typed it. undefined shows up:

when a variable is declared but not initialized (let x;)
when an object property doesn't exist (obj.missing)
when an array index is out of bounds (arr[999])
when a function returns nothing (function f() {})
when optional chaining short-circuits (a?.b?.c)
when destructuring a missing key (const { x } = {})
when a function parameter is omitted (f() where f(x))

Some libraries normalize on null. Some normalize on undefined. Most do whatever the original author thought was right that day. You do not get to know in advance which one any given codepath will hand you.

So we write defensive code:

if (x !== null && x !== undefined) { ... }

Or the clever version:

if (x != null) { ... }   // != catches both null and undefined

The clever version works because of loose equality. So now your "safe" check requires the operator your linter has spent five years trying to get rid of. Every codebase has both forms. Every code review is a small argument about which to use. None of this is solving a problem; it is mopping up a design choice from 1995.

Mistake 2: falsy

The second mistake is bigger. JavaScript decided that in any boolean context — if, while, &&, ||, the ternary — six values should evaluate as false:

0
""
false
null
undefined
NaN

This is called falsy. It is the most dangerous abstraction in the language.

The danger is that falsy conflates absence with valid-but-zero/empty. Those are different things, and "different things" is the entire reason types exist.

A counter at 0 is not absent. An empty string is a valid string. NaN is a real result in the number domain. false is the boolean answer to a question, not a missing one. null and undefined mean something else entirely.

function showCount(count) {
  if (count) {                    // ← bug
    document.body.append(`Total: ${count}`)
  } else {
    document.body.append("No items")
  }
}

showCount(0)   // "No items"  ← wrong, there are 0 items, that IS a count

Every JavaScript developer has shipped this bug. It comes back in different shapes:

if (user.name)            // fails on legit empty name
if (config.timeout)       // fails on legit 0 timeout
if (response.body)        // fails on legit empty-string body
if (array.length)         // works (kind of) but only by coincidence

The fix is to write the actual question you meant:

if (count != null)             // "is this absent?"
if (count > 0)                 // "is this positive?"
if (count !== 0)               // "is this nonzero?"
if (typeof count === "number") // "is this a number at all?"

Each of those is a different question. if (count) answered all four at once and produced one answer for all four. That's not a feature; that's a category error baked into the language.

What strict TypeScript does fix, and what it doesn't

TypeScript's strictNullChecks is genuinely good. It forces you to type optionality explicitly (T | null, T | undefined) and rejects code that doesn't handle the absence case. It also gives you ?? (nullish coalescing) and ?. (optional chaining), which treat null and undefined together — an implicit acknowledgement from the language designers that distinguishing them was a mistake.

What strict TS does NOT fix:

null and undefined are still two distinct values. The type system tracks them; the runtime still has both.
The falsy rule is unchanged. TS does not touch JavaScript's runtime semantics. if (count) still silently fails on 0. The compiler will not warn you. Your linter might, if you've configured it. Most people have not.

TS strict is the best you can do without designing a new language. It is also not enough.

What scrml does

scrml is a new language, so it has the privilege of fixing both mistakes at the source.

There is one value for absence. It is called not. The keywords null and undefined are not valid identifiers in scrml source. Writing them is a compile error.

let x = not                    // ok
let x = null                   // E-SYNTAX-042
let x = undefined              // E-SYNTAX-042

There is one way to check for absence. It is is not.

if (x is not) { handleAbsence() }
if (x is some) { handlePresence(x) }

There is no falsy rule. Boolean contexts accept booleans. The only false thing is false. The only absent thing is not. 0 is a number. "" is a string. They are not "false-ish" or "absent-ish" — they are zero and empty, respectively, and you have to ask the question you actually meant.

if (count is not) { ... }      // "no value"
if (count == 0) { ... }        // "zero"
if (count > 0) { ... }         // "positive"

Three different questions. Three different answers. The language refuses to let you confuse them.

Narrowing is enforced by the type system. When a variable is T | not, you can't use it as T until you've handled the absence case. The way you do that is given:

${
    given x => {
        // x is T here, not T | not
        // the | not has been narrowed away
        use(x)
    }
}

The given block runs only when x is some, and inside it the compiler narrows x to its non-absent type. Forgetting to handle absence is not "best practice"; it is a compile error.

For pattern matching:

${
    match x {
        not       => handleAbsence()
        given x   => handlePresence(x)
    }
}

Match on a T | not without a not arm? Compile error (E-MATCH-012). Exhaustiveness for absence is forced.

What about the JS interop?

The compiler emits plain JavaScript. JavaScript libraries hand back null and undefined indiscriminately. Doesn't this all fall apart at the boundary?

No. is not compiles to a check that catches both:

x is not       →    (x === null || x === undefined)
x is some      →    (x !== null && x !== undefined)
given x        →    if (x !== null && x !== undefined) { ... }

The chaos stays in the runtime. The source stays clean. When a JS library returns either, the absence check still works correctly. You write one form; the compiler emits the safe form for you.

The same applies to SQL results (?{}.get() returns T | not, not T | null), to optional fields, to function returns. Everywhere absence might come from, the language gives you one way to express it and one way to handle it.

"But this is more keystrokes than `if (x)`"

Yes. Eight characters more, in fact: if (x is some) vs if (x).

It is also a category of bug that does not exist in scrml programs. The line where you wrote if (count) and thought you handled zero correctly is the line that cost your team a day of debugging. The line where you wrote if (user) and the API returned null once for one user is the line that put a 500 in front of one customer for a week.

Languages do not have a moral obligation to be terse. They have a moral obligation to make wrong programs hard to write. JavaScript, by treating absence as identical to zero and empty and false in boolean contexts, made a particular class of wrong program very easy to write. We have been paying for that ever since with sentry alerts, post-mortems, and "I swear it worked locally."

The trade is a few extra characters for one fewer category of recurring bug. It is the most obvious trade in language design and it is the trade JavaScript could not make in 1995, because it had a ten-day deadline and was trying not to break the web.

We don't have that excuse anymore.

Try it / follow along

Site: https://scrml.dev
Repo + spec: https://github.com/bryanmaclee/scrmlTS — see compiler/SPEC.md §42 for the full not semantics
Intro post: Introducing scrml
The living compiler post: It's Alive — A Living Compiler
X / Twitter: @BryanMaclee — there's a thread version of this argument up there if you prefer the rant in 14 tweets.

If null vs undefined has bitten you in the last month, I want to hear the story. If you think falsy is fine and I'm overreacting, I want to hear that too — there's a defence of the design choice and I haven't heard one that holds up under load yet.

scrml's Living Compiler

Bryan MacLee — Sun, 19 Apr 2026 16:06:01 +0000

It's Alive

"It's alive! It's alive!" — Henry Frankenstein, 1931

If you read the intro post, you saw scrml's headline pitch: one file, full stack, compiler does everything.

This post is about the design choice that scares me the most. The one where, every time I describe it, somebody pauses and says wait, you're doing **what?

scrml has a living compiler (in phase 4 of impl). The codegen layer isn't fixed. Community-contributed transformations compete for usage, the population decides which graduate to canonical, and the compiler evolves with the ecosystem instead of with a release cycle.

That's the monster. Let me explain how it's stitched together.

The frozen compiler is convenient until it isn't

Compilers, in the normal world, are frozen things. A standards committee meets. RFCs are drafted. Implementations follow. New patterns wait years. The codegen layer, in particular, is sacred; it's where the language's identity lives.

That model has good reasons behind it. Stability. Reproducibility. A clear blame surface when something breaks. You know what your compiler does because someone with merge rights decided what it does.

The cost of that model is everything that doesn't fit committee timelines. A new browser API ships and you wait three years for the codegen to adopt it. A pattern emerges in real apps that would compile to better output, but the maintainers can't justify the risk to existing users. A specific domain (games, dashboards, embedded) has codegen needs that the general-purpose path will never optimise for.

In the JavaScript world, we route around this with userland libraries. We npm install the new pattern, write a runtime adapter, and pay the cost in bundle size, indirection, and supply-chain risk. The compiler stays frozen and the ecosystem grows messy around it.

scrml does the opposite. The compiler stays alive and the package layer goes away.

The argument I'm extending

This is not my argument. It's an argument gingerBill has been making for years with Odin, and I'm pushing it one step further.

gingerBill's case — in talks, blog posts, and the Odin language itself — is that the package layer is the problem. Central registries, transitive dependencies, opaque update cadences aren't solving a problem; they are the problem, restated. Odin's answer is radical and consistent: no package manager, no registry, vendor everything, dependencies-as-liabilities.

scrml inherits that premise completely. Every time you read "no npm, no transitive trust, vendor-everything" in this post, that's gingerBill's argument, and it's worth reading him directly before reading the rest of what I'm about to say.

The living compiler, is scrml taking his rejection seriously. Then going one step further. Odin rejects package management. scrml rejects it too, and then notices that even if you vendor every library, the compiler itself is still a frozen dependency — and freezing the compiler has its own costs. So we keep the registry idea, but make it distribute compiler transformations instead of runtime code, and let the population drive what graduates.

That's the moon-shot. It only exists because gingerBill already made (proved, IMO) the first half of the argument.

What "living" means

Inside the compiler, a scrml program decomposes into a graph of transformation signatures — typed shapes that say "this construct, in this context, with this type, becomes this output." A signature is the unit of codegen. The compiler ships with one canonical transformation per signature in the box, and that's what your code compiles down to today.

Now imagine the next part:

A developer writes an alternative transformation for one of those signatures. Maybe their version emits faster code for hot paths. Maybe it produces smaller output for a specific browser target. Maybe it specializes for an architecture pattern the canonical path didn't anticipate. They publish it.

Other developers can opt in to that alternative — explicitly, by use-ing it, the same way you'd use a syntax extension or a stdlib module. The compiler picks it up, runs it through a verification pass, and starts emitting that codegen for matching signatures in projects that opted in.

The interesting part isn't that alternatives can exist. It's what happens next.

The compiler observes which alternatives are getting used. Population-level signals — adoption, regression rate, performance deltas, error counts — feed a quality gate. Alternatives that stay green and grow adoption past a threshold graduate to canonical. Alternatives that regress get demoted. The canonical transformation for a given signature is whatever the population, through actual use, has converged on.

The compiler evolves with the ecosystem. Not with a release cycle. Not with a committee. But with the people writing apps in it.

This isn't a package registry. It's a registry of transformations.

npm distributes runtime code. Every dependency you install becomes JavaScript that runs in your app. Transitive dependencies pull more JavaScript. The blast radius of a single bad package is everything downstream that runs your code, including code you didn't write and didn't read.

scrml's living-compiler registry distributes compile-time codegen patterns. A transformation alternative isn't a runtime library — it's a function that takes an AST node and emits compiled output. It runs once, at build time, in the compiler's process. Its output is the same kind of plain JS the canonical transformation would have emitted. There's no transitive dependency tree because compiled output isn't a dependency. Your app links against the compiler, not against the alternatives the compiler considered.

That changes the threat model in ways that matter:

No transitive runtime exposure. A bad transformation can emit bad code, but it can't pull in 47 sub-dependencies that each get to run on your users' devices.
Output is verifiable. The compiler runs a verification pass over emitted code (sandboxed evaluation, type-shape check, regression suite). A transformation that emits something the verifier rejects never ships.
The blast radius is the signature, not the app. A bad transformation affects the codegen for one signature, in projects that explicitly opted in to that alternative. It doesn't get to touch unrelated parts of your code.

npm's problem isn't packages. It's the runtime trust model around packages. The living-compiler registry has a different trust model because it distributes a different thing.

Yes, you're allowed to be suspicious — there's a trust gradient

Three tiers, named at project creation. Pick the one that matches your paranoia level:

scrml init (default — the living compiler in full). Quality-gated alternatives are pulled in based on signatures in your code. Audit log committed to your repo so you can see exactly which transformations the build used. Fast, evolves with the ecosystem, takes the population's word for what's canonical.

scrml init --stable (lock-file mode). Same registry, but pinned. Your project locks the transformation set at init time and only updates when you say so. You get the population's choices but on your release cadence, not theirs. This is the closest analogue to a typical "lockfile + versioned deps" workflow.

scrml init --secure (vendor-everything). No registry trust. All transformations live in your repo, copied in as source, audited by you. The compiler never reaches out at build time. The population's signals don't touch your build. This is the gingerBill / Odin philosophy: dependencies are liabilities; vendor everything.

The default is the bold one. The other two exist because not every project wants to be on the bleeding edge of the ecosystem's collective opinion, and that's fine.

The objections, plus what we're doing about them

"You're going to need telemetry to make this work." Yes — opt-in, anonymised, signature-shaped (no source code, no project identifiers). Population signals are aggregate counts: how many projects use this transformation, what fraction green-build with it, what their build-time and bundle-size deltas are. Projects on --secure participate in nothing. Projects on --stable opt in to whichever surface they want. The default tier is opt-in by default to a minimal surface; the consent prompt at scrml init is concrete about what's measured.

"The supply-chain attack surface is enormous." It's a real surface, and it's the reason the verification pass and signing exist. Every transformation runs in a sandbox at build time. Output is verified against a regression suite before it can graduate. Transformations are cryptographically signed by their authors. Compromised authors get revoked at the registry layer. The threat model is documented and the mitigations are first-class concerns, not afterthoughts.

"Who decides when an alternative graduates?" The population does, against quality gates the compiler enforces. Humans confirm. The graduation step is git-committable to the registry repo, which is itself open. This is closer to the canary-test model used in big distributed systems than to a maintainer-pick or vote. The system recommends, humans decide, the recommendation is auditable.

"This sounds like it could go very wrong." It could. The closing argument for it is also the closing argument against it: the compiler grows with its users. If the ecosystem produces bad transformations, the ecosystem owns that. There is no maintainer-of-last-resort to blame. The compiler's identity is whatever the people writing apps in it have collectively converged on. That's either the most exciting governance story in language design or a slow-motion catastrophe, and honestly the difference depends on what we build now to make verification, signing, and graduation work as well as the verification of the language itself.

Where it is today

scrml is pre-1.0. The full living-compiler vision — the registry, the graduation pipeline, the telemetry surface — is Phase 4 work. The foundations are landing now: the use keyword that lets you opt in to vendored extensions, the vendor/ model that makes copy-everything trivial, the ^{} meta layer that lets local code override compiler behaviour today. Those are the rails the registry rolls onto.

What that means for you, today:

The use vendor:my-extension import path works — you can write a transformation alternative as a vendored module and use it in your project right now. It just doesn't graduate anywhere.
The compiler is open and watchable. You can read the canonical transformations, write your own, and see what the registry will eventually distribute.
The threat model and verification design are in the open. The deep-dives are in the scrml-support repo under docs/deep-dives/.

If the idea sounds interesting, the most useful thing is to write a couple of vendor: transformations now and see how it feels. The shape of those is the shape of what the registry will distribute later.

It's alive

Henry Frankenstein doesn't get to keep his monster. The story is about hubris, the cost of stitching things together you didn't fully understand, and the obligations you take on when you give something its own life.

I think about that a lot. The living compiler is the part of scrml's design that makes me, the maintainer, least comfortable — and the part I'm most certain about. Frozen compilers are conservative for good reasons. Frozen compilers also calcify. The web ecosystem already has one of those, and we paid for it with node_modules.

The bet here is that giving the codegen layer its own life, with verification and signing and population-level quality gates around it, lets the ecosystem grow without needing a kingmaker — and that the obligations that come with that are obligations worth taking on.

It's alive. Now we have to keep it that way.

Try it / follow along

Landing + quick start: https://scrml.dev
Repo + spec: https://github.com/bryanmaclee/scrmlTS
X / Twitter: @BryanMaclee
Living-compiler design notes: look in scrml-support/docs/deep-dives/ for transformation-registry-design-2026-04-08.md and debate-transformation-registry-2026-04-08.md — the architecture is open-source, including the arguments against it.

If this design choice seems sketchy. Thats because it is. I am building this language to push the envelope into the future, or off a cliff. Either way, should be a fun ride.

Reply here, on X (@BryanMaclee), or open an issue on the repo.

Introducing scrml: a single-file, full-stack reactive web language

Bryan MacLee — Sat, 18 Apr 2026 21:28:46 +0000

Introducing scrml

scrml is a compiled language that puts your markup, reactive state, scoped CSS, SQL, server functions, WebSocket channels, and tests in the same file — and lets the compiler handle everything in between. The compiler splits server from client, wires reactivity, routes HTTP, types your database schema, and emits plain HTML/CSS/JS. No build config, no separate route files, no state-management library, no node_modules mountain.

This post is an introduction. scrml is pre-1.0 and not production-ready — the language surface will still shift, some diagnostics are rough, and I'm sharing it now mainly to get design feedback before things calcify.

Why another language?

A typical modern web app spreads across five or more tools and files. You have React on the client, Node or Next on the server, a state library (Redux, Zustand, Jotai...), a separate router config, an API layer keeping client and server types in sync, a CSS system, a build toolchain, and your ORM. Each of those tools makes reasonable local choices, and collectively they produce the sprawl everyone complains about but nobody quite knows how to fix.

What if the compiler owned the whole stack?

That's the bet. Same file, same language, one compile pass. The compiler knows which functions are reachable from the client and which stay on the server, because it parses both. It knows which @var is read in which DOM node, because it builds a dependency graph. It knows your SQL schema, because it ran the schema extraction. So it can enforce things across those boundaries instead of leaving them to runtime coordination.

A counter in one file

Here's the entire program:

<program>

${
  @count = 0
  @step = 1

  function increment() { @count = @count + @step }
  function decrement() { @count = @count - @step }
  function reset()     { @count = 0 }
}

<div class="flex flex-col items-center gap-6 p-8 min-h-screen bg-gray-50">
  <h1 class="text-3xl font-bold text-gray-800">Counter</h1>
  <p class="text-6xl font-bold text-blue-600">${@count}</p>

  <div class="flex gap-2">
    <button class="px-5 py-2 text-lg bg-red-500 text-white rounded-lg cursor-pointer hover:bg-red-600" onclick=decrement()>−</button>
    <button class="px-5 py-2 text-lg bg-gray-200 rounded-lg cursor-pointer hover:bg-gray-300" onclick=reset()>Reset</button>
    <button class="px-5 py-2 text-lg bg-green-500 text-white rounded-lg cursor-pointer hover:bg-green-600" onclick=increment()>+</button>
  </div>

  <label class="flex items-center gap-2 text-sm text-gray-600">
    Step:
    <input type="number" class="w-16 p-1 text-center border border-gray-300 rounded" bind:value=@step min="1" max="100">
  </label>
</div>

</program>

@count and @step are reactive variables — language primitives, not library wrappers. bind:value is two-way binding. onclick=increment() wires the handler. The compiler emits direct DOM updates (no vdom, no diffing) for every site that reads @count. The Tailwind utility classes above compile via a built-in Tailwind engine — no tailwind.config.js, no postcss, no content scan — so utility CSS works out of the box and you can still drop into a scoped #{} block when utilities aren't enough.

Three things that are different

1. State is a first-class type

< Card> declares a state type; <Card> instantiates one. HTML elements like <input> and <form> are state types — the language treats them uniformly with your own types. Every state value flows through match, through fn signatures, and across the server/client boundary with static checks. The compiler knows what shape a Contact is, which fields are protected (server-only), and which routes need to serialize what. You write Types once; they hold across the stack.

2. Any variable can carry a compile-time contract

Contracts come in three flavours.

Value predicate — reject out-of-range writes:

@price: number(>0 && <10000) = 1

Presence lifecycle (lin) — must be consumed exactly once; the compiler refuses a double-use or a silent drop:

lin token = fetchCsrfToken()
submitForm(token)    // consumed — compile error if you used it twice or not at all

State transitions — only legal moves allowed:

type DoorState:enum = { Locked, Unlocked }

< machine name=DoorMachine for=DoorState>
    .Locked   => .Unlocked
    .Unlocked => .Locked
</>

@door: DoorMachine = DoorState.Locked
@door = .Unlocked    // ok
@door = .Locked      // ok — Unlocked => Locked is declared

The < machine> rejects illegal transitions at both compile time and runtime. If the compiler can prove the destination is unreachable from the current state, it errors then and there. If something dynamic sneaks through (a network response, user input routed into a transition), the runtime enforces the same table. One source of truth, two layers of enforcement.

3. N+1 gets rewritten automatically

A pattern like this:

for (let user of users) {
  let orders = ?{`SELECT * FROM orders WHERE user_id = ${user.id}`}.all()
  ...
}

becomes a single WHERE user_id IN (...) pre-fetch plus a keyed Map lookup. Because the compiler owns both the query context and the loop context, it can see that the per-iteration query is a safe batching candidate. When it isn't safe, you get a D-BATCH-001 diagnostic with the exact disqualifier and a ?{...}.nobatch() escape hatch.

Measured on on-disk WAL bun:sqlite (median of 50 iterations after 5 warmups, table size 1000, full results in benchmarks/sql-batching/RESULTS.md):

N	Baseline (ms)	Optimized (ms)	Speedup
10	0.0111	0.0057	1.95×
100	0.1068	0.0410	2.60×
500	0.5124	0.1654	3.10×
1000	1.0490	0.2625	4.00×

Upper bound is SQLITE_MAX_VARIABLE_NUMBER (32,766). Network-attached storage would widen the gap further.

There's more that didn't fit here

To keep this post focused, I left out:

WebSocket channels (<channel>) — auto-generated upgrade routes, auto-reconnect, and @shared vars that sync across connected clients
Web Workers as nested <program>s — heavy work compiles to a worker with typed RPC and supervised restarts
Scoped CSS (#{}) that applies only inside the component it's declared in
Typed SQL where the schema extraction feeds back into type checking
Inline tests as language constructs

Each is worth its own writeup. I'll do follow-up posts if there's interest.

Where it is today

Pre-1.0 — breaking changes likely, rough edges, not production-ready
MIT — compiler is fully public
6,800+ tests passing — every language feature is test-covered
~45 ms — full compile for a TodoMVC-sized app on a 2021 laptop
Bun today — Node/Deno ports are possible but not priorities

Try it / follow along

Landing + quick start: https://scrml.dev
Repo + spec: https://github.com/bryanmaclee/scrmlTS
X / Twitter: @BryanMaclee
The spec (if you want the depth): compiler/SPEC.md in the repo — sections 14 (types), 18 (match), 42 (lifecycle), 51 (machines), 52 (server authority) are the meatiest.

Feedback on the design is the thing I'm actually optimising for right now. If something looks wrong, looks over-engineered, looks like it'll trip on a real app — I want to hear about it here, on X (@BryanMaclee), or as an issue on the repo. Happy to chase threads before the language surface calcifies.

Forem: Bryan MacLee

Null was a billion-dollar mistake. Falsy was the second.

Null was a billion-dollar mistake. Falsy was the second.

Mistake 1: two values for "no value"

Mistake 2: falsy

What strict TypeScript does fix, and what it doesn't

What scrml does

What about the JS interop?

"But this is more keystrokes than if (x)"

Try it / follow along

scrml's Living Compiler

It's Alive

The frozen compiler is convenient until it isn't

The argument I'm extending

What "living" means

This isn't a package registry. It's a registry of transformations.

Yes, you're allowed to be suspicious — there's a trust gradient

The objections, plus what we're doing about them

Where it is today

It's alive

Try it / follow along

Introducing scrml: a single-file, full-stack reactive web language

Introducing scrml

Why another language?

A counter in one file

Three things that are different

1. State is a first-class type

2. Any variable can carry a compile-time contract

3. N+1 gets rewritten automatically

There's more that didn't fit here

Where it is today

Try it / follow along

"But this is more keystrokes than `if (x)`"