DEV Community: Mat Weiss

Five Ways to Fail a Transport

Mat Weiss — Tue, 26 May 2026 12:36:00 +0000

(Ruuk shares syntax with F#. A brief introduction to F# is provided here if you need it.)

As a tech lead, I'd set minimum standards for API error handling — every call covers 400, 401, 403, 500. In ticket reviews I'd still find three failure scenarios in the notes and one in the code. Developers had spotted the cases; the language gave them nowhere permanent to put that knowledge.

The knowledge of which errors to handle was always there. It lived in tickets, in team standards, in code comments — and it degraded, because none of those places were connected to the compiler.

I started designing op because I wanted that knowledge to have a durable home in the code itself — a declaration that names every outcome an operation can produce, enforced at every call site. The first article in this series argued that this intent already exists in every codebase — in Javadoc, in JSDoc comments, in OpenAPI response schemas — but lives where the compiler can't see it. op moves it into the declaration.

The Binary Split

Every mainstream approach to error handling asks the same question first: did it work, or didn't it? Try/catch, Result, sealed exception hierarchies — they all partition outcomes into two buckets. If your background is Java or C#, you've reached for this with custom exception hierarchies or result wrapper classes — the intent is always the same: name the failure modes, make them visible to callers. But the binary framing works only when an operation genuinely has one way to succeed and one way to fail. This isn't always the best way to model many domain operations.

The previous article ended with a transporter that uses F#'s Result type:

type TransporterFailure =
    | SignalLost of lastCoords: string
    | PatternDegradation of integrity: float
    | TargetShielded

let beamUp target =
    if target.SignalStrength > 0.8 then
        Ok target.Name
    elif target.SignalStrength > 0.4 then
        Error (PatternDegradation target.SignalStrength)
    else
        Error (SignalLost target.LastKnownCoords)

The discriminated union inside Error means the failure modes are typed and named. Pattern matching means you can handle each one. This is genuinely good — I prefer it to exception hierarchies, or status codes. But three properties of the binary model compound at scale, regardless of which language you use.

New outcomes slip through the cracks. Add InsufficientPower to the transporter. In Java, callers that catch the base TransporterException still compile. In C#, a switch with a default arm still compiles. In F#, callers that forward the Error side with Result.map still compile. The call sites that explicitly enumerate cases will break — as they should — but the ones that handle errors generically don't. That's the pattern I saw as a tech lead. Developers would identify an error case during implementation, document it, and move on — and nothing in the toolchain pushed back. What if the compiler could make this impossible?

Success is more than one thing. Every binary error model — try/catch, Result<T, E>, Go's (value, error) — gives you exactly one success channel. But many domain operations have more than one meaningful success path. An upsert either created a new record or updated an existing one. A negotiation reached a full agreement or a provisional ceasefire. Both outcomes are successes, but they require different handling. Model two success paths and you're either misclassifying one as a failure or nesting another dispatch layer inside the success channel, where callers can process the value without ever distinguishing between the two paths.

This is the constraint we rarely notice: working in languages where success is modeled as singular can train us not to see cases where it isn't.

Outcomes are peers, not subcategories. Even in the best case — F#'s pattern matching, where the compiler verifies every arm — the binary structure leaks into every call site:

match beamUp target with
| Ok name -> $"Transport complete. {name} is aboard."
| Error (SignalLost coords) -> $"Signal lost at {coords}."
| Error (PatternDegradation integrity) -> $"Pattern at {integrity}."
| Error TargetShielded -> "Cannot beam through shields."

The domain has four outcomes; the type has two. Every failure arm spells out Error (...) as a preamble before reaching the actual case. The same ceremony appears in Java sealed hierarchies, C# result wrappers, and Go error returns. The wrapper changes; the two-bucket structure doesn't — and it shows everywhere the code touches the result.

Parameter intent is implicit. A real transporter operation has a target, a source location, a destination pad, and an operator. Most languages handle this with positional parameters or named arguments — beamUp(target, surface, pad, operator) or beamUp(target: riker, from: surface). Named arguments are a real improvement over positional-only. But the names are ad hoc: one operation uses from, another uses source, a third uses origin. Nothing enforces consistency across the codebase, and the compiler doesn't verify that a parameter labeled from actually plays the role of a source.

These properties are fine for small codebases where a team can hold the conventions in working memory. They compound as the number of operations and call sites grows — particularly in agentic workflows where the code is written by one system and reviewed by another.

What a Better Approach Could Look Like

These properties point toward three design criteria:

All outcomes must be handled at every call site. F#'s match and Java's switch expressions on sealed types already enforce exhaustive coverage — that's strong, and it's the right foundation. The remaining gap is call sites that forward, transform, or ignore the result without matching. When someone adds a sixth outcome, every call site should break until it's handled — not just the ones that happen to use match.

Outcomes should be peers, not wrapped. An operation that can produce five results should declare five outcomes at the same level. SignalLost is not a sub-category of "error" — it's a domain result as legitimate as Transported. The caller should handle each one directly, without unwrapping a success or error container first.

Parameters should carry semantic roles. Named parameters are good. A small, fixed vocabulary of parameter roles is better. If every operation in the codebase uses from to mean "source" and to to mean "destination" — not because of a naming convention, but because the language defines those roles and the compiler verifies them — then call sites are consistent by construction. A developer who learns the role vocabulary once can read any operation's call site without checking its signature.

This matters for agentic coding too. Language models trained on natural language have already internalized from and to as directional roles. A fixed vocabulary gives a model the same reference point as the human reviewer — generated call sites are consistent not by training luck, but by structural constraint.

Introducing `op`

Ruuk's op keyword declares a domain operation as a first-class language construct. A domain operation is any action with outcomes that callers need to handle differently — a database write, an API call, a state transition, a validation check. Pure transformations and internal helpers stay as regular let functions.

Here's the transporter. pub marks the operation as visible to other modules — the same access modifier you'd find in Rust:

pub op beamUp =
    payload target: CrewMember
    from surface: PlanetarySurface
    to pad: TransporterPad
    by operator: CrewMember
    outcomes =
        | Transported of CrewMember
        | SignalLost of lastCoords: String
        | PatternDegradation of integrity: Float
        | TargetShielded
        | InsufficientPower

Five outcomes, declared as peers. Each carries its own data — SignalLost carries coordinates, PatternDegradation carries an integrity reading, TargetShielded and InsufficientPower carry nothing. No outcome is privileged as "success" or "error" — each is a peer-level domain result.

The parameters have roles. payload marks the main data argument. from, to, and by are prepositions that describe each parameter's relationship to the operation. These aren't arbitrary labels chosen by the developer — they're drawn from a small, fixed vocabulary that Ruuk defines: payload, subject, from, to, by, via, in, at, for. Every operation in every codebase uses the same words for the same meanings.

The roles appear at the call site:

beamUp riker from planetSurface to padOne by laForge

Read it out loud: "beam up Riker from the planet surface to pad one by La Forge." Many languages have named parameters. The fixed role vocabulary adds consistency across the entire codebase — you don't learn source on one operation and origin on another. Every operation that takes something from somewhere uses from. Swap from and to and the compiler rejects it — TransporterPad is not a PlanetarySurface. The vocabulary is small enough to memorize in minutes, and once you know it, every call site reads the same way.

The op declaration is the contract. It tells every other module what beamUp needs and what it can produce. The implementation is a separate let binding:

let beamUp (target: CrewMember) (surface: PlanetarySurface)
           (pad: TransporterPad) (operator: CrewMember) =
    if pad.powerLevel < minimumPower then
        InsufficientPower
    elif surface.shielded then
        TargetShielded
    elif target.signalStrength > 0.8 then
        Transported target
    elif target.signalStrength > 0.4 then
        PatternDegradation target.signalStrength
    else
        SignalLost target.lastKnownCoords

The separation is deliberate. From another module, you read the op declaration — the contract — which tells you what to provide, what role each argument plays, and what can come back. The implementation is an internal detail. This is the three-party model from the first article in practice: the human defines the declaration, the agent generates the implementation body, and the compiler verifies that the body satisfies the contract.

Handling Outcomes with `|> on`

Outcomes are handled with |> on, which integrates directly into Ruuk's pipeline syntax:

beamUp riker from planetSurface to padOne by laForge
|> on Transported crew   -> printfn $"Transport complete. {crew.name} is aboard."
|> on SignalLost coords  -> printfn $"Signal lost at {coords}. Dispatching shuttle."
|> on PatternDegradation integrity ->
    printfn $"Pattern integrity at {integrity}. Boosting signal."
|> on TargetShielded     -> printfn "Cannot beam through shields. Hailing target."
|> on InsufficientPower  -> printfn "Rerouting power to transporter systems."

Each |> on arm matches one outcome and binds its data. Transported crew binds the returned CrewMember to crew. SignalLost coords binds the coordinates. TargetShielded carries no data, so there's no binding.

Compare this to the Result matching from earlier. The outcomes are flat — one level, five arms, each handled directly. There's no Ok/Error wrapper to spell out on every arm. The pipeline reads top to bottom: the operation produces a result, and each rail leads to its own destination.

If you've encountered Scott Wlaschin's railway-oriented programming, this is the same mental model extended from two rails to N — reflecting the actual structure of domain operations rather than forcing them through a binary split.

Exhaustive Handling

F# match already fails to compile when an arm is missing — that's the foundation op builds on. The difference is what happens when a developer reaches for a wildcard:

match beamUp target with
| Ok name -> $"Transport complete. {name} is aboard."
| Error (SignalLost coords) -> $"Signal lost at {coords}."
| Error (PatternDegradation integrity) -> $"Pattern at {integrity}."
| _ -> "Something went wrong."  // compiles; TargetShielded silently swallowed

This compiles. The wildcard arm satisfies the compiler while silently discarding any outcome it matches. |> on has no equivalent. Remove an arm and there's nowhere for that outcome to go:

beamUp riker from planetSurface to padOne by laForge
|> on Transported crew   -> printfn $"Transport complete. {crew.name} is aboard."
|> on SignalLost coords  -> printfn $"Signal lost at {coords}."
|> on PatternDegradation integrity -> printfn $"Pattern at {integrity}."
|> on TargetShielded     -> printfn "Cannot beam through shields."
-- InsufficientPower is missing

This does not compile:

Unhandled outcome: InsufficientPower
  in beamUp call at TransporterRoom.rk:14

Every declared outcome must be handled or explicitly marked as deferred. There's no catch-all to hide behind.

The practical consequence: if you add a new outcome to beamUp — say WarpFieldInterference because the ship is about to jump to warp — the compiler produces an error at every call site that doesn't handle it or explicitly mark it as deferred. That error list is your work queue. The decision can't be deferred silently.

Progressive Development with `todo`

If you've worked under schedule pressure — and you have — you might see a tension with exhaustive handling. The compiler now requires every outcome to be accounted for before the code compiles. But the whole motivation for op was that schedules don't leave room to handle everything at once. Demanding completeness on day one would just trade one problem for another.

todo resolves this. It's the developer's explicit acknowledgment to the compiler: I know this outcome needs handling. Not today.

beamUp riker from planetSurface to padOne by laForge
|> on Transported crew   -> printfn $"Transport complete. {crew.name} is aboard."
|> on SignalLost coords  -> printfn $"Signal lost at {coords}."
|> on PatternDegradation integrity -> printfn $"Pattern at {integrity}."
|> on TargetShielded     -> todo
|> on InsufficientPower  -> todo

This compiles. The compiler emits warnings — "todo: TargetShielded outcome unhandled at line 5" — but not errors. If TargetShielded fires at runtime, todo panics with a clear message pointing to the unhandled outcome and its location.

todo works anywhere an expression is expected. In a function body you haven't implemented yet. In a match arm you'll fill in later. In a pipeline handler you're deferring. Every todo in the codebase is a compiler-tracked work item. The warnings list is your checklist; the compiler maintains it automatically.

This is the difference that mattered to me: without a declaration like op, unhandled error paths can become invisible — they compile silently, and under schedule pressure, the team moves on. With op and todo, the sprint can end with incomplete handling, but every gap is tracked, visible, and named. That visibility is just as critical in agentic workflows — an agent that generates an implementation can't silently skip an outcome, and a reviewer scanning todo warnings sees exactly which decisions remain open. A language should be a feedback system during development, not just a gatekeeper at the end.

A Richer Example: Routing Emergency Power

The transporter demonstrates outcomes and parameter roles. A more complex operation shows how they compose.

During a Red Alert, Engineering needs to reroute power from non-essential systems to critical ones — shields, weapons, life support. But a reroute isn't all-or-nothing: the holodeck might spare 300 units without shutting down completely, even when 500 were requested. The operation has two distinct success paths and several failure paths:

pub op routePower =
    payload amount: PowerUnits
    from source: ShipSystem
    to target: ShipSystem
    by officer: CrewMember
    outcomes =
        | FullyRouted of PowerAllocation
        | PartiallyRouted of PowerAllocation
        | InsufficientPower of available: PowerUnits
        | SystemOffline of system: ShipSystem
        | OverloadRisk of currentLoad: Float
        | UnauthorizedAccess

At the call site, the roles make the operation self-documenting:

routePower 500 from holodecks to shields by laForge

"Route 500 power units from holodecks to shields by La Forge." A developer cold-reading this code doesn't need the signature to tell which system gives power and which receives it.

Chaining this with the alert status makes a realistic pipeline:

pub op setAlertStatus =
    payload status: AlertStatus
    by officer: CrewMember
    outcomes =
        | AlertSet of AlertStatus
        | AlreadyAtStatus
        | InsufficientRank

setAlertStatus Red by picard
|> on AlertSet _ ->            -- discard the AlertStatus value
    routePower 500 from holodecks to shields by laForge
    |> on FullyRouted alloc ->
        printfn $"Power rerouted: {alloc.amount} units to shields."
    |> on PartiallyRouted alloc ->
        printfn $"Partial reroute: {alloc.amount} units to shields. Requesting auxiliary power."
    |> on InsufficientPower available ->
        printfn $"Only {available} units available. Requesting auxiliary power."
    |> on SystemOffline system ->
        printfn $"Cannot draw from {system.name}: system offline."
    |> on OverloadRisk load ->
        printfn $"Shield grid at {load}% capacity. Reroute would overload."
    |> on UnauthorizedAccess ->
        printfn "Officer lacks authorization for power routing."
|> on AlreadyAtStatus ->
    printfn "Already at Red Alert."
|> on InsufficientRank ->
    printfn "Only senior officers can set alert status."

The nesting mirrors the domain logic. You can only reroute power after setting the alert succeeds — and each level handles its own outcomes completely. The compiler verifies coverage at both levels independently.

FullyRouted and PartiallyRouted are both successes — the power moved — but they require different responses. With Result, expressing two success paths means either misclassifying one as an error or wrapping both in another union inside Ok, where callers can ignore the distinction. With op, both sit at the top level as peers, and the compiler holds every call site to both.

The Comparison

The argument for op is not that functions-returning-unions are wrong. They're a good pattern — better than exceptions, better than status codes, better than unchecked error returns. op builds on that foundation by making the properties structural rather than advisory:

Concern	Function + DU	`op`
Parameter roles	Named arguments (ad hoc)	Fixed role vocabulary (compiler-verified)
Exhaustive handling	Compiler-checked in `match` expressions	Compiler-checked at every call site, no wildcards
Adding an outcome	Breaks `match` arms; forwarding sites compile unchanged	Breaks call sites until handled or marked `todo`
Outcome contract location	Separate return type	Declared with the operation
Readable without implementation	Often split between function and result type	Declaration is the contract
Binary success/failure bias	Baked into `Result<T, E>`	All outcomes are peers

F# provides the foundation op builds on — exhaustive matching, typed unions, immutable data. The table highlights the specific gaps that remain when Result is the primary abstraction for domain operations: call sites that forward or ignore results aren't covered by exhaustive checking, the binary split can obscure domain structure, and parameter semantics depend on naming conventions. op is Ruuk's attempt to close those gaps.

When to Use `op` vs `let`

Not everything is a domain operation. op is for actions with multiple outcomes that callers handle differently — service calls, state transitions, validations. Pure transformations, utility functions, and internal helpers stay as regular let functions. If a function has one return path with no alternative outcomes, let is the right tool. The parameter roles offer a practical test: if payload, from, to, and the rest don't fit naturally, the operation probably isn't a domain action — it's a transformation.

What's Next

op builds on F#'s strengths — exhaustive matching, typed unions, immutable data — and addresses the gaps this series cares about. Parameter roles replace ad hoc naming conventions. The binary Ok/Error split gives way to peer-level outcomes. And exhaustive handling extends from match expressions to every call site. The declaration carries it all, and the compiler enforces it everywhere. That's the foundation the rest of the series builds on.

But the declaration doesn't yet control what each operation can see or when it can run.

The next article introduces projections — type-level views that control which fields an operation can access. If the transporter's beamUp operation shouldn't see a crew member's medical records, that restriction should be structural, not a runtime filter somebody remembers to apply. Projections make information boundaries part of the type system.

After that: typestate, where the compiler tracks what state an entity is in and prevents operations that don't make sense in that state. You shouldn't be able to beam someone up who hasn't been cleared for transport — and the type system should enforce that, not a runtime guard.

The transporter is a single operation. Real starship procedures chain dozens of them, and when step five fails, steps one through four may need to be undone. That's the saga article. But first, we need to control what operations can see and when they can act.

Ruuk is pre-alpha. If these ideas resonate, follow along on GitHub and weigh in on the discussions.

From Braces to Pipes

Mat Weiss — Tue, 26 May 2026 12:30:00 +0000

The previous article argued that compilers could check more than they currently do — and that the agentic coding era makes this urgent. The articles that follow demonstrate specific features in Ruuk, a language designed around that idea. But Ruuk's syntax is based on F#, and if you've never seen an ML-family language, the examples will be harder to follow than they need to be.

This article is a warp-speed tour of F# syntax — just enough to read the Ruuk code in the rest of the series. If you've written C#, Java, or TypeScript, nothing here is conceptually alien. The ideas have direct parallels; the notation is just different. And to keep things interesting, we'll model our examples around the operational systems of a certain starship.

Why Fsharp

The choice of F# as Ruuk's syntactic foundation wasn't personal preference. Before I'd decided on paradigm or syntax style, I studied how programmers actually read code — drawing on cognitive linguistics research. Two findings shaped the design. First, people tend to read code the same way they read prose: linearly, left to right, top to bottom. Nested function calls like toUpper(trim(getName(user))) force inside-out reading — you start at the innermost call and work outward. Fluent method chaining — user.getName().trim().toUpper() — solves the reading-order problem, but it ties each step to a method defined on the preceding type. A pipeline like user |> getName |> trim |> toUpper reads in the same order things happen, and the functions are standalone — they compose freely without needing to live on a class. ML-family languages build around this style, and that made them a natural place to start.

Second, natural language encodes relationships through prepositions — from, to, by, in — and humans process these almost reflexively. That observation led directly to Ruuk's parameter roles, which you'll see in the next article: beamUp riker from planetSurface to padOne by laForge reads the way you'd describe the operation out loud. The syntax isn't ML-flavored because ML is elegant (though it is). It's ML-flavored because that family gave Ruuk a strong foundation for readable, linear code.

Values and Functions

F# uses let to bind a name to a value. If you're coming from a C-family language, think const — bindings are immutable by default.

let shipName = "Enterprise"
let registry = "NCC-1701-D"
let maxWarpFactor = 9.6

No type annotations. F# infers types from usage — shipName is a string, maxWarpFactor is a float. You can annotate explicitly, but idiomatic F# lets the compiler do the work:

let shipName: string = "Enterprise"   // valid, but unnecessary here

Functions use the same let keyword. There's no function or func or fn — a binding that takes parameters is a function:

let warpSpeed factor =
    factor * 299792.458

let greeting name rank =
    $"{rank} {name}, reporting for duty."

warpSpeed takes one argument and returns a float. greeting takes two and returns a string. The compiler infers all of it. No return keyword either — the last expression in a function is its return value.

And if you call warpSpeed with the wrong type, the compiler catches it immediately:

warpSpeed "fast"
// Error: This expression was expected to have type 'float'
//        but here has type 'string'

No runtime surprise. The compiler saw that warpSpeed multiplies its argument by a float, inferred the parameter must be a float, and rejected "fast" at compile time.

If you're used to braces and semicolons: whitespace is significant in F#. Indentation defines scope, similar to Python. The body of warpSpeed is indented under its declaration — that's what makes it the body, not a pair of curly braces.

These three properties — immutable bindings, type inference, and functions defined with let — are the foundation everything else in this tour builds on.

Records

The type keyword defines new types. A record is a named collection of fields — the closest analog is a C# record or a TypeScript object literal with a fixed shape:

type CrewMember = {
    Name: string
    Rank: string
    Department: string
    ClearanceLevel: int
}

Creating a record instance looks like this:

let picard = {
    Name = "Jean-Luc Picard"
    Rank = "Captain"
    Department = "Command"
    ClearanceLevel = 10
}

Notice there's no new CrewMember(...). F# infers that picard is a CrewMember because the field names match — only one record type in scope has that exact set of fields. Type inference extends beyond simple values.

Field access uses dot notation:

let name = picard.Name   // "Jean-Luc Picard"

Records are immutable. You don't modify a record — you create a copy with specific fields changed using the with keyword:

let promoted = { picard with Rank = "Admiral" }

picard still has Rank = "Captain". promoted is a separate value with Rank = "Admiral" and everything else copied. If you've used spread syntax in JavaScript ({ ...picard, rank: "Admiral" }), it's the same idea with a compile-time guarantee that the field names and types are correct.

Immutable records with copy-on-write are the default data model in F# — and in Ruuk. You define the shape, the compiler tracks it, and transformations produce new values instead of mutations.

Lists and Pipelines

F# lists use square brackets. Items are separated by semicolons, or by newlines if each item is on its own line:

let bridge = [
    { Name = "Picard"; Rank = "Captain"; Department = "Command"; ClearanceLevel = 10 }
    { Name = "Riker"; Rank = "Commander"; Department = "Command"; ClearanceLevel = 9 }
    { Name = "La Forge"; Rank = "Lt. Commander"; Department = "Engineering"; ClearanceLevel = 8 }
    { Name = "Crusher"; Rank = "Commander"; Department = "Medical"; ClearanceLevel = 8 }
    { Name = "Worf"; Rank = "Lieutenant"; Department = "Security"; ClearanceLevel = 7 }
    { Name = "Data"; Rank = "Lt. Commander"; Department = "Operations"; ClearanceLevel = 8 }
]

F# lists are immutable. Adding an element produces a new list; the original doesn't change.

The real power of lists in F# is how you process them. The pipe operator |> takes the result of the left side and passes it as the last argument to the function on the right. This lets you write data transformations as a top-to-bottom pipeline:

let seniorStaff =
    bridge
    |> List.filter (fun m -> m.ClearanceLevel >= 8)
    |> List.sortByDescending (fun m -> m.ClearanceLevel)
    |> List.map (fun m -> m.Name)
// ["Picard"; "Riker"; "La Forge"; "Crusher"; "Data"]

Read it top to bottom: start with the bridge crew, keep only those with clearance 8 or above, sort by clearance descending, extract their names. Each step feeds into the next.

fun m -> m.ClearanceLevel >= 8 is a lambda — same idea as m => m.ClearanceLevel >= 8 in C# or JavaScript, different arrow. List.filter, List.map, and List.sortByDescending are direct counterparts to LINQ's Where, Select, and OrderByDescending, or Java's filter, map, and sorted.

If you've chained LINQ methods or Java streams, pipelines will feel natural. The difference is that pipes compose standalone functions rather than calling methods on an object. Data flows through; functions don't need to know about each other.

Discriminated Unions

We're at warp now — this is the feature that matters most for the rest of the series.

Records describe things that have multiple fields. Discriminated unions describe things that can be one of several cases. The type keyword does both jobs.

A simple union with no associated data:

type Department =
    | Command
    | Engineering
    | Medical
    | Science
    | Security
    | Operations

Each case is a distinct value. This replaces the Department: string we used earlier in CrewMember — instead of hoping someone types "Engineering" correctly, the compiler knows exactly which values are valid:

type CrewMember = {
    Name: string
    Rank: string
    Department: Department
    ClearanceLevel: int
}

let worf = {
    Name = "Worf"
    Rank = "Lieutenant"
    Department = Security
    ClearanceLevel = 7
}

No quotes around Security — it's a value of type Department, not a string. Try assigning Department = "Security" and the compiler rejects it. Try assigning Department = Tactical and the compiler rejects that too — Tactical isn't one of the cases.

If you're coming from Java or C#, this looks like an enum, and for simple cases it works the same way. The difference is that each case can carry its own data:

type AlertStatus =
    | Green
    | Yellow of reason: string
    | Red of threat: string * shieldsUp: bool

Green carries nothing. Yellow carries a reason. Red carries a threat description and whether shields are raised. These aren't three variations of the same data shape — each case has its own structure. Try modeling this with a C# enum and you'll end up with a class hierarchy or nullable fields. The union makes it one type.

let currentAlert = Yellow "Unidentified vessel on long-range sensors"
let battleStations = Red ("Romulan warbird decloaking", true)

Ruuk's outcomes — which we'll see in the next article — are discriminated unions. When an operation can succeed, fail, or partially fail in domain-specific ways, each outcome is a case with its own data. The compiler knows all of them and can verify you've handled every one.

Option and Result

Two discriminated unions show up so often in F# that they're built into the standard library. Rust has the same pair (Option and Result); if you've used those, this is identical in intent.

Option represents a value that might not exist. It has two cases: Some with a value inside, or None. This replaces null — and unlike null, you can't use the value without first deciding what absence means.

let findCrewMember name =
    bridge |> List.tryFind (fun m -> m.Name = name)

let found = findCrewMember "Worf"          // Some { Name = "Worf"; ... }
let missing = findCrewMember "Kirk"        // None

List.tryFind returns an Option<CrewMember>, not a CrewMember. You can't call .Name on the result directly — the compiler knows it might be None. You have to unwrap it first — which means deciding what happens when nothing is found. No NullReferenceException three layers away from the actual problem.

Result represents an operation that can succeed or fail, with data in both cases: Ok carries the success value, Error carries the failure value.

type TransporterFailure =
    | SignalLost of lastCoords: string
    | PatternDegradation of integrity: float
    | TargetShielded

type TransporterTarget = {
    Name: string
    SignalStrength: float
    LastKnownCoords: string
}

let beamUp target =
    if target.SignalStrength > 0.8 then
        Ok target.Name
    elif target.SignalStrength > 0.4 then
        Error (PatternDegradation target.SignalStrength)
    else
        Error (SignalLost target.LastKnownCoords)

beamUp returns Result<string, TransporterFailure> — either a name on success or a typed failure explaining what went wrong. If you're coming from Java or C#, your instinct might be to throw a SignalLostException, a PatternDegradationException, and so on — one exception class per failure mode. That encodes the failures, but it doesn't make them visible in the function's signature. Callers compile fine whether they catch anything or not. Java's checked exceptions tried to fix this, but the syntactic overhead led to so much catch-and-swallow boilerplate that C#, Kotlin, and most modern Java frameworks chose not to adopt the pattern. With Result, the failure cases live in the return type — they're part of the contract, not a side channel — and the compiler won't let you ignore them.

Ruuk inherits Option and Result from this lineage and extends the idea further. Where F# gives you two slots — Ok or Error — Ruuk's operations declare arbitrary domain-specific outcomes as first-class members of the signature. The next article shows what that looks like.

Pattern Matching

Once you inspect an Option or Result, F# gives you a precise tool for handling its cases: match/with, which branches on the shape of data.

let transportReport result =
    match result with
    | Ok name ->
        $"Transport complete. {name} is aboard."
    | Error (SignalLost coords) ->
        $"Signal lost at {coords}. Dispatching shuttle."
    | Error (PatternDegradation integrity) ->
        $"Pattern integrity at {integrity}. Boosting signal."
    | Error TargetShielded ->
        "Cannot beam through shields. Hailing target."

Each branch matches a specific shape and destructures its data. Error (SignalLost coords) doesn't just check that the result is an error — it checks that it's specifically a SignalLost error and pulls out the coordinates in one step. No casting, no instanceof, no nested if chains.

Here's the important part: the compiler checks that every case is handled. Remove the TargetShielded branch and the compiler warns you:

Incomplete pattern matches on this expression.
For example, the value 'Error TargetShielded' may indicate
a case not covered by the pattern(s).

This is exhaustive checking. The compiler knows every case in the union and verifies you've accounted for all of them. Add a new case to TransporterFailure — say WarpFieldInterference — and every match expression that doesn't handle it gets flagged. F# isn't alone here — Java's switch expressions on sealed types and Rust's match enforce the same guarantee. But F# has had it from the start, and it's one of the language's strongest properties: a closed, compiler-verified contract between the type definition and every piece of code that consumes it. It's the property the rest of this series depends on. When Ruuk declares that an operation has four outcomes, this is the mechanism that ensures every caller handles all four.

What's Next

That's enough F# to read Ruuk. Six concepts: let bindings, records, lists and pipelines, discriminated unions, Option/Result, and pattern matching with exhaustive checking. If you followed the transporter example — a function that returns a typed result, where pattern matching lets the compiler check every handled failure mode — you have the mental model for what comes next.

The next article introduces Ruuk's op keyword and its outcomes block — where these F# foundations meet domain-specific compiler enforcement. The compiler takes it from there.

For deeper F# coverage, Scott Wlaschin's F# for Fun and Profit and Isaac Abraham's Get Programming with F# are both excellent starting points for developers coming from OOP languages.

Ruuk is pre-alpha. If these ideas resonate, follow along on GitHub and weigh in on the discussions.

Your Compiler Is Missing from the Party

Mat Weiss — Thu, 30 Apr 2026 12:00:00 +0000

Handwriting code is the new cursive. AI agents write code competently, and they're improving fast. My recent agentic work spans refactoring C++ machine learning libraries, writing CLIs in Rust, building web apps in ASP.NET, and shipping mobile apps in Flutter. For the mechanical parts — scaffolding, boilerplate, repetitive transformations — agents handle it well. I've used them to write entire features on their own as well.

It makes you wonder, if the agent writes the code, is the language is an implementation detail — and the intuition makes sense: why care about syntax you'll never type? But the language isn't just what the agent writes in. It's what the compiler checks, what the human reviews, and what determines how fast the feedback loop closes. Agentic coding raises the stakes for language design, and points toward specific properties a language should have.

Better Compiler Feedback Multiplies Agent Productivity

My agentic coding experience has varied by language. Part of that is training data — AI models have seen more code in some languages than others. But the larger factor is whether mistakes are caught at compile time or runtime, which determines how quickly the loop closes.

In Rust, when an agent generates something wrong, the compiler identifies the exact location, names the violated constraint, and usually suggests a fix. The agent iterates on that feedback directly — no execution required. When checks happen at runtime instead, there's an extra round-trip: generate code, execute tests, parse results, feed output back to the agent. More wall time per iteration, more tokens spent on test output instead of code. Same agent, longer loop, higher cost per correction. And those runtime checks are only as good as the inputs that exercise them. Communities built around runtime-checked languages know this well — it's why they invest heavily in defensive testing, property-based tools like Hypothesis, and comprehensive test suites. But even thorough tests depend on the paths you think to exercise. A compile-time check flags the error unconditionally.

This isn't a judgment on any particular language — it's a property of where in the cycle errors surface. The industry has started redesigning CLI tools for agents — Trevin Chow's seven principles for agent-friendly CLIs captures the pattern: structured output, unambiguous interfaces, clear error signals. The same thinking applies to compilers. The compiler is the agent's primary feedback surface — and most compilers were designed before agentic coding existed.

Better compiler output is the starting point. The deeper question is what classes of mistakes the compiler can catch. The best current compilers handle memory errors (Rust), type mismatches (TypeScript), and null dereferences (Kotlin). Entire categories of domain mistakes remain invisible: unhandled operation outcomes, invalid state transitions, missing field mappings when converting between data representations. These aren't obscure edge cases — they slip past review and surface in production.

The Development Model Needs a Third Party

Our current approach to AI coding is a two-party arrangement: humans describe intent, agents write code. Somebody is missing the party.

The danger isn't that AI writes bad code. It's that humans lose the ability to evaluate what AI writes — and the two-party model accelerates this. The volume of AI-generated code is already outpacing review capacity; the trend is toward reviewing less, not more. That makes the compiler more load-bearing, not less. A smarter AI doesn't close this gap on its own — even the best engineer benefits from code review, because independent verification catches what self-consistency misses. The same principle applies to generated code, except the stakes are higher: the reviewer understands less of the codebase with each generation cycle.

The Rust model points at the answer: compiler-enforced properties rather than runtime hopes. The question is whether we can extend that from memory safety to operational semantics. Expanded compiler checking gives us a basis for trusting AI-generated code — not because the AI earned that trust, but because an independent third party verified the structural claims. Checks and balances: human + compiler + AI, each with a distinct responsibility.

The human defines the operation's shape: its outcomes, state transitions, data projections. The AI generates the implementation body. The compiler stands between them, rejecting anything that violates the declared structure. This changes what a developer needs to review. The programmer's job is to get the declaration right — to ensure the outcome variants are exhaustive, the state transitions are valid, the field projections are accurate. That's the work only a human can do: verifying that the declaration honestly represents the domain. Once that's done, the compiler owns enforcement everywhere.

The languages most of us work in weren't designed for the assumption that you'd be reading tens of thousands of lines generated by someone else, at volume, under time pressure. That's the new reality. The closer a language's constructs map to domain concepts, the less translation the reader's brain performs — and the faster a developer can audit generated code for correctness.

Domain Knowledge Belongs in the Declaration

The common thread between better compiler feedback, the three-party model, and cheaper review is semantic content — how much meaning the language lets you encode, and how much of that meaning the compiler verifies.

Current compilers have limited capability to check domain rules. Your service calls a payment gateway — the response can mean charged, declined, fraud-held, or gateway failure. Most languages give you a status code and a body; whether you distinguish "declined" from "fraud hold" depends on your discipline, not the compiler. A User has twenty fields; an API response should expose five of them. Derive the response type by hand, add a field to User next quarter, and now you're trusting every downstream DTO to have been updated.

The convention of documenting this is everywhere — Javadoc's @throws, Python's Raises, OpenAPI's response schemas. The problem is that none of it is compiler-visible. You can document four outcomes and handle three. The gap stays invisible until production. Here's a typical pattern:

/**
 * @throws DeclinedError
 * @throws FraudHoldError
 * @throws GatewayError
 */
async function chargeCard(
  req: ChargeRequest,
  gateway: PaymentGateway,
): Promise<Receipt> {
  // ...
}

The return type promises a Receipt — that's the happy path. The three failure modes live in a JSDoc comment the compiler will never read. A caller that ignores all three error cases compiles without a warning. The information is there, but it's decorative.

Here is the same operation in Ruuk, a language designed to include this information where the compiler can verify it:

pub op chargeCard =
    payload req: ChargeRequest
    via gateway: PaymentGateway
    outcomes =
        | Charged of Receipt
        | Declined of DeclineReason
        | FraudHold of ReviewId
        | GatewayError of ErrorDetail

This declares not just inputs but what role each plays (payload is the data being acted on, via is the external system being called) and what outcomes the caller must handle. If you call chargeCard and don't handle the FraudHold outcome, it doesn't compile. The meaning you would have put in a comment is now visible to the compiler — and enforced by it.

The same declaration that gives the compiler more to verify also makes the code faster to cold-read. A developer scanning AI-generated code can evaluate chargeCard's shape in seconds: what it takes, where the data goes, what can go wrong. No implementation diving required.

This design direction asks developers to formalize what they already know — it's on the whiteboard, in the docs, in comments scattered through the codebase. You already know your payment operation has four possible outcomes. The language asks you to type that in. The compiler takes it from there.

Conclusion

Agentic coding hasn't reduced the importance of language design — it's exposed where it needs to grow. The properties that improve the agentic loop are the same ones that improve human review: more meaning in the syntax, more verification in the compiler, less translation between what the code says and what the domain demands.

That points toward a class of language, not a single answer. Ruuk is my attempt to build one — designed from the start for the world where agents write the code and humans verify the shape. Hopefully it won't be the only attempt, and competition here is genuinely good. The industry needs more people thinking about this problem.

The articles that follow make the design concrete. The next piece is a fast tour of the OCaml/F# syntax Ruuk builds on — enough to read the examples without getting lost. After that: how operations and outcomes give the compiler visibility into failure modes, and how projections enforce structural rules when data crosses boundaries. The chargeCard declaration above is the destination. The series shows how you get there.

Ruuk is pre-alpha. What I can show right now is the thinking behind it — and a place to engage with the design before it solidifies. If the ideas in this article resonates, follow along on GitHub and weigh in on the discussions. The best languages get shaped by the people who care about the problems they solve.

Code Intelligence Is Being Retrofitted. Ruuk Builds It In.

Mat Weiss — Fri, 17 Apr 2026 12:01:48 +0000

A response to Thoughtworks Technology Radar Vol. 34, Blip 18: Code Intelligence as Agentic Tooling

Blip 18 of the April 2026 Thoughtworks Radar names a real problem: AI coding agents are effectively blind to the meaning of the code they operate on. The Radar's answer is richer tooling — LSP integrations, OpenRewrite's Lossless Semantic Tree, JetBrains MCP servers.

That's the practical path for mainstream languages. But it's still using the AST to infer intent. What would it look like to use the AST to see it?

Ruuk — a language I'm designing — takes a different position: the constraints worth enforcing should be in the language itself.

What the AST Cannot Tell You

Take a typical enterprise operation: approving an order. In Java, an agent with full LSP access sees something like this:

public ApprovalResult approveOrder(OrderId orderId, CSR csr) {
    Order order = orderStore.findById(orderId);
    // ... validation logic
    // ... state transition
    // ... outcome handling
}

The agent knows the function name, its signature, its call sites, and the types it touches. What it doesn't know is more consequential:

order must be in Created state for this call to be valid. Calling it on a Cancelled order is a logic error, not a type error — the compiler won't catch it, and neither will the agent.
There are exactly two outcomes — Approved and Rejected — and callers must handle both. The agent has to read the implementation to find out.
This is an instantaneous state transition, not a long-running process. That distinction matters for error handling and compensation strategy. The function signature doesn't say.
orderStore is being mutated — it's an entity undergoing state change, not a read-only data source. The agent can't tell that from the call.

Modern Java closes some of these gaps. Sealed classes and pattern matching (Java 21+) give you exhaustive outcome handling. Some languages go further: TypeScript's discriminated unions and Rust's typestate patterns encode more intent into the type system. But even in those languages, the precondition that the order must be in Created state remains a convention, not a compiler-checked constraint. The resource mutation role is still invisible. The state machine is still implicit. They moved the needle on what can happen; they didn't touch what must be true before or what kind of change is occurring.

An agent can reconstruct those properties for any well-written function by reading its implementation and tests. The problem is scale. Across a codebase of thousands of operations, inference compounds uncertainty. It fails hardest on the code that needs agents most: legacy systems, inconsistent patterns, missing tests. Structural declarations don't degrade. The thousandth operation is as machine-readable as the first.

What Ruuk Exposes at Declaration Time

In Ruuk, the same operation looks like this:

resource Order = Created -> Approved -> Shipped -> Delivered

op approveOrder (subject: Order<Created>) (by: String) (goal: OrderStore) =
    performs Order.Created -> Order.Approved
    outcomes
        | Approved of Order<Approved>
        | Rejected of String

Everything the Java version hid is in the declaration. The precondition is in the type: Order<Created>. Passing an Order<Cancelled> is a compile error. The state transition is explicit in the performs clause. The outcomes are enumerated, and the compiler verifies that every call site handles both. The subject role marks the order as the entity being changed; the goal role marks the store as the mutation target, distinct from a read-only data source.

The compiler checks these declarations against the implementation. If the function body transitions to a state that doesn't match the performs clause, it won't compile. If you add an outcome variant without updating call sites, they won't compile. Declarations can't drift from reality because they're verified at compile time, then erased. Zero runtime cost.

That's a meaningful difference from design-by-contract predecessors like Eiffel and JML, where contracts were primarily runtime-checked or relied on external verification tools. In Ruuk, the declaration is the constraint, and the compiler enforces it statically.

I designed it this way because the information always existed. Every team I've worked with on enterprise applications knew their preconditions, their state machines, their failure modes. They just had no place to put that knowledge where the compiler could use it.

From this declaration alone, an agent can answer — without reading one line of implementation — every question the Java version left open. The Radar points to the AST and the richer Lossless Semantic Tree as the right representations for agent tooling. Those capture structure: how code is organized, what the syntactic relationships are. Ruuk's declarations go further — they capture meaning: what must be true, what can happen, and what kind of change is occurring.

What Could an Agent Do With This?

Impact analysis. When Order gains a new field, an agent can ask: which projections include this field? A Ruuk projection is a typed, compiler-checked subset of a resource's fields. CustomerOrderView = Order only { id; customer; total } declares exactly which fields downstream consumers can see. Finding every projection affected by a schema change is a structural query, not a grep through the codebase.

Outcome coverage. Which operations have outcomes stubbed with todo? In Ruuk, todo is a compiler-tracked placeholder, not a comment. Which call sites are missing a handler for a specific variant? The answers are compiler-verified facts, not heuristic inference.

State machine queries. A resource like Order carries its current state in its type: Order<Approved>, Order<Shipped>. The compiler knows which operations are valid for which states. What transitions are reachable from Order<Created>? What operations apply when the order is in transit? The answers come from the declared lifecycle, queryable and independent of implementation.

Role-based refactoring. An agent told to "add audit logging to every operation that mutates order state" doesn't need to read method bodies. It queries the declared subject role across every operation, identifies the affected call sites, and makes the change. The semantic structure tells it exactly where to edit and what contract to preserve.

In each case, the agent spends fewer tokens reconstructing context and gets closer to a correct edit on the first pass. That's a ceiling that better tooling can't raise if the language never captured the information.

Blip 18 asks how to make agents smarter about existing code. That's the right question for existing codebases, and the Radar's answers are practical.

Ruuk is exploring a different one: what happens when the language itself captures enough domain semantics that agents — and humans — can reason from declarations alone?

That's a bet on language design, not tooling. Ruuk is in early development, and none of this has been tested at scale with real agents. But I believe the overhead pays for itself: what Ruuk asks you to declare is what you already know. The cost isn't in knowing your preconditions and state machines. It's in not having a compiler that checks them.

The language design is documented on GitHub, where I'm using Discussions to think through design decisions in the open. I also write about Ruuk's design rationale here on dev.to.

DEV Community: Mat Weiss

Five Ways to Fail a Transport

The Binary Split

What a Better Approach Could Look Like

Introducing op

Handling Outcomes with |> on

Exhaustive Handling

Progressive Development with todo

A Richer Example: Routing Emergency Power

The Comparison

When to Use op vs let

What's Next

From Braces to Pipes

Why Fsharp

Values and Functions

Records

Lists and Pipelines

Discriminated Unions

Option and Result

Pattern Matching

What's Next

Your Compiler Is Missing from the Party

Better Compiler Feedback Multiplies Agent Productivity

The Development Model Needs a Third Party

Domain Knowledge Belongs in the Declaration

Conclusion

Code Intelligence Is Being Retrofitted. Ruuk Builds It In.

What the AST Cannot Tell You

What Ruuk Exposes at Declaration Time

What Could an Agent Do With This?

Introducing `op`

Handling Outcomes with `|> on`

Progressive Development with `todo`

When to Use `op` vs `let`