DEV Community: Mat Weiss

When Step Five Fails, Undo Steps One Through Four

Mat Weiss — Tue, 16 Jun 2026 13:00:00 +0000

The previous articles built up a picture of what a compiler can verify about individual operations: their outcomes, what data they can see, what state they require. The operations article introduced N-track pipelines where every outcome gets handled and errors can accumulate along the way. If every step is a pure transformation, that model is sufficient — errors collect, the caller handles them, nothing external has changed.

But real procedures aren't pure transformations. An away mission involves assembling the team, briefing them, beaming them down, establishing contact, collecting samples, and beaming them back. Each step commits real effects — crew assignments change, transporter logs update, communication channels open. When step four fails, steps one through three have already happened. Accumulated errors tell you what went wrong. They don't undo what already happened.

I explored error recovery for effectful pipelines — steps that commit external state, not just transform data. The answer was compensation: each forward step paired, when possible, with the action that reverses or settles it. Ruuk's saga keyword makes that pairing a first-class part of the declaration.

The Problem: Distributed Commitment

The challenge isn't failure itself. The challenge is partial failure after partial commitment.

A pipeline handles failure cleanly when no step has committed external state. If step three returns a failure outcome, steps one and two produced data that's still local — nothing external has changed. The failure is just an outcome, not a cleanup problem.

But starship operations commit to external systems. Beaming a team down changes their location in the ship's records. Opening a communication channel allocates subspace bandwidth. Logging samples in the science database creates records other systems depend on. These aren't local transformations — they're effects that persist whether the procedure succeeds or not.

When establishContact fails after beamDownTeam succeeded, the team is on the planet surface with no confirmed communication link. The correct response is to beam them back up — but that compensation logic lives in a catch block somewhere, and whether it matches the current beam-down procedure depends on whether someone updated both when the procedure changed.

The standard approach: execute each step, check the result, compensate on failure.

async function conductAwayMission(mission, team, planet) {
  const assigned = await assembleTeam(team, mission);
  if (!assigned.ok) return missionFailed(assigned.error);

  const briefed = await briefTeam(assigned.team, mission);
  if (!briefed.ok) {
    await releaseTeam(assigned.team);
    return missionFailed(briefed.error);
  }

  const landed = await beamDown(briefed.team, planet);
  if (!landed.ok) {
    await debriefTeam(briefed.team);
    await releaseTeam(assigned.team);
    return missionFailed(landed.error);
  }

  const contact = await establishContact(landed.team, planet);
  if (!contact.ok) {
    await beamUp(landed.team);
    await debriefTeam(briefed.team);
    await releaseTeam(assigned.team);
    return missionFailed(contact.error);
  }

  // ... remaining steps
}

This is competent, readable code. It handles each failure and compensates correctly. But the compensation list grows with every step — each failure handler must repeat every previous compensation in reverse order. Add a step between briefTeam and beamDown and every subsequent handler needs updating. The relationship between a forward step and its compensation is implicit: releaseTeam undoes assembleTeam, but you learn that by reading the error handler, not the step declaration. And nothing verifies that every effectful step has a corresponding undo.

Sagas as Declarations

A saga declares steps in order; each step that commits external state declares its compensating operation:

pub saga ConductAwayMission =
    subject mission: Mission<Approved>
    payload team: List<CrewMember>
    payload planet: Planet

    step assembleTeam
        compensate releaseTeam

    step briefTeam
        compensate debriefTeam

    step launchMission
        compensate abortMission
        performs Mission.Approved -> Mission.InProgress

    step beamDown
        compensate beamUp

    step establishContact

    step collectSamples

    step beamUp

    step completeMission
        performs Mission.InProgress -> Mission.Completed

    outcomes =
        | MissionComplete of Mission<Completed>
        | ContactFailed of reason: String
        | TransporterFailure of TransporterError
        | TeamUnavailable of missing: List<String>

Read it as a mission briefing: assemble the team (if it fails later, release them), brief them (debrief if needed), launch the mission, beam them down (beam them back up if something goes wrong), establish contact, collect samples, beam up, and complete the mission with a state transition from InProgress to Completed.

establishContact and collectSamples have no compensate clause. establishContact is a read/verify step — if it fails, there's nothing to undo beyond the earlier compensations. collectSamples is the forward payload of the mission — if sample collection fails, the earlier steps still need unwinding, but "uncollecting" samples isn't a meaningful operation.

The final beamUp step (the planned return, not the compensation) and completeMission also lack compensation — by the time you reach them, the mission has substantively succeeded. completeMission performs the typestate transition from article 5, moving the mission from InProgress to Completed.

The saga's outcomes block declares the saga-level results — the outcomes a caller must handle. When a step fails, the saga unwinds completed steps that declared compensation and surfaces the failure as the appropriate saga outcome.

Automatic Compensation on Failure

If establishContact fails after beamDown, launchMission, briefTeam, and assembleTeam have all succeeded, the saga unwinds automatically in reverse order:

beamUp — compensates beamDown (team is returned to the ship)
abortMission — compensates launchMission (mission is settled as aborted)
debriefTeam — compensates briefTeam (team status is reset)
releaseTeam — compensates assembleTeam (crew assignments are freed)

Last completed, first compensated. The compensation order is the reverse of the execution order — the same principle as unwinding a call stack, but applied to domain operations with real-world effects.

The developer doesn't write this unwind logic. The saga declaration defines it. The compensation for beamDown is beamUp, declared on the same line. The relationship between forward step and undo is visible, explicit, and maintained in one place.

What the Compiler Verifies

Compensation completeness. Every step that calls a mutating operation should declare a compensating action. The compiler warns on steps that modify external state without a compensate clause — not an error, because some mutations genuinely can't be undone (you can't un-send a transmission), but a signal that the developer should make that judgment explicitly.

Operation existence. Each operation named in step and compensate must exist in scope. You can't reference a compensation operation that hasn't been defined.

Performs consistency. If a saga step uses performs, the same validation rules from the typestate article apply: the subject parameter must match the source state, the success outcome must match the target state, no mismatched transitions.

Order guarantees. Compensation executes in reverse execution order by definition. The saga declaration makes this explicit — reading the steps top to bottom tells you the compensation order bottom to top. That leaves less runtime coordination logic to get wrong.

An agent generating a saga gets the same guardrails. The compiler warns on uncompensated mutations whether a human or an agent wrote the declaration — the structural check doesn't depend on who authored the code.

A Richer Example: Ship Repair Workflow

Away missions are dramatic but linear. Ship repairs show how sagas handle more complex workflows with multiple external system interactions:

pub saga RepairCriticalSystem =
    payload system: ShipSystem
    payload damage: DamageReport
    by chief: CrewMember

    step assessDamage

    step allocateRepairTeam
        compensate releaseRepairTeam

    step requisitionParts from supplyStore
        compensate returnParts to supplyStore

    step takeSectionOffline
        compensate bringBackOnline

    step performRepair

    step runDiagnostic

    step certifyRepair
        performs RepairOrder.InProgress -> RepairOrder.Completed

    outcomes =
        | Repaired of RepairOrder<Completed>
        | PartsUnavailable of needed: List<PartId>
        | DiagnosticFailed of failures: List<String>
        | SectionCritical of reason: String

Each forward step reads naturally with its compensation: allocate a team / release the team, requisition parts / return the parts, take the section offline / bring it back online. The parameter roles from article 3 appear in the steps — requisitionParts from supplyStore — making the saga declaration read like a procedure manual.

If runDiagnostic fails after the repair is done, the saga unwinds: bring the section back online, return the parts, release the team. The repair itself may need manual intervention — there's no compensate on performRepair because "un-repairing" isn't a meaningful action. That's a deliberate design choice, visible in the declaration.

Sagas vs. Pipelines

Both sagas and pipelines compose sequential operations. The distinction matters:

A pipeline passes data forward. Each step transforms the previous step's result. N-track pipelines can accumulate multiple errors along the way, but the model assumes no step has committed external state — failures are outcomes to report, not effects to undo.

A saga coordinates effects. Each step may commit external state — a transport, a database write, a resource allocation. If a later step fails, committed state must be undone. The saga manages the compensation stack.

Use a pipeline when steps are pure transformations or when a single system handles rollback automatically (a database transaction). Use a saga when you're coordinating across multiple systems that don't share a transaction boundary — a transporter system, a personnel database, a supply chain, a communication array.

What Sagas Complete

The previous article ended with "What Compounds" — each feature was designed for practical relief and arrived at structural correctness. Sagas extend the pattern one more time. I was exploring error recovery in effectful pipelines, and what started as a way to declare compensation alongside forward steps turned into compiler-verified workflow integrity.

With scattered compensation logic, the answer to "what happens if the transporter fails mid-mission?" is: "our error handlers call the right cleanup functions." That answer depends on every handler being correct, complete, and synchronized with the forward path. With a saga declaration, the answer is the declaration itself: beamDown has compensate beamUp. When someone adds a step, the syntax prompts the question "does this step need compensation?" — and the compiler warns if a mutating step omits one. The forward path and the compensation path live together, so they evolve together.

Series Conclusion

This series has built up a picture of what a compiler could verify about the code agents write and humans review.

Operations and outcomes (article 3) give the compiler visibility into what an operation means — not just its return type, but its domain-specific results. The compiler holds every caller to every outcome.

Projections (article 4) give the compiler control over what each operation can see. Data access boundaries are structural properties of the type, not runtime filters maintained separately.

Typestate (article 5) gives the compiler control over when operations can run. State preconditions are in the type system, not in runtime guards. Invalid transitions are compile errors.

Sagas (this article) give the compiler visibility into multi-step workflows and their compensation. The forward path and the undo path are declared together, maintained together, and verified together.

Each feature stands on its own, but the compounding is the point. An operation with typed outcomes, scoped to a projected data view, guarded by typestate, coordinated within a saga — that's a level of structural verification that testing and code review alone don't reliably achieve. The compiler holds invariants that humans struggle to keep in working memory. In an era where agents write code at volume and humans review it under time pressure, that starts to look less like a nice-to-have and more like part of the architecture of trust.

Ruuk is in alpha. The syntax will continue to evolve and the implementation has a long road ahead. But the design criteria — compiler-visible domain semantics, structural enforcement over behavioral convention, progressive development that doesn't sacrifice rigor — are the properties I think the agentic era makes newly important. If these ideas resonate, give ruuk a spin; 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.

This article was created with the help of AI

You Can't Launch What Hasn't Been Approved

Mat Weiss — Tue, 09 Jun 2026 13:00:00 +0000

I designed resources because I was tired of reasoning about async I/O.

Every developer knows the ritual: open a connection, do work, close the connection. Handle the case where the open failed. Handle the case where you're writing to something that isn't ready yet. Handle the case where you close something twice. Add async to the mix and the state space multiplies — is the request in flight? Has the response arrived? Am I holding a promise or a result?

The logic is a state machine, and most developers could draw it on a whiteboard in thirty seconds. But the compiler can't see the whiteboard. The states live in a boolean field or an enum, the transitions live in runtime guards, and a caller who uses a resource in the wrong state gets an exception instead of a compile error.

I wanted the compiler to track that state in the program's model: whether a connection value represents an open channel, whether a request is still in flight, whether a response has arrived. This doesn't make the outside world infallible — networks still fail, files still disappear, other systems still change state — but it does mean your own code can't call an operation with a value in the wrong modeled state.

A Subspace Channel

Ruuk's resource keyword declares an entity with named states that the compiler tracks. Here's a subspace channel — the Enterprise's long-range communication link:

pub resource SubspaceChannel =
    state Idle
    state Open
    state Transmitting
    state Terminal
        state Closed
        state Failed

An idle channel has type SubspaceChannel<Idle>. An open channel has type SubspaceChannel<Open>. These are different types — operations that expect one reject the other.

The Terminal grouping declares Closed and Failed as intentional endpoints: states the channel doesn't leave. The compiler won't warn about missing outgoing transitions from terminal states.

Operations declare which state they require using the subject role — a parameter role from the op vocabulary introduced earlier in the series, which marks the resource being acted on:

pub op openChannel =
    subject channel: SubspaceChannel<Idle>
    payload frequency: SubspaceFrequency
    outcomes =
        | Connected of SubspaceChannel<Open>
        | FrequencyBusy
        | OutOfRange

pub op send =
    subject channel: SubspaceChannel<Open>
    payload message: Message
    outcomes =
        | Transmitting of SubspaceChannel<Transmitting>
        | SendFailed of SubspaceChannel<Failed>

pub op awaitResponse =
    subject channel: SubspaceChannel<Transmitting>
    outcomes =
        | Received of response: Message, channel: SubspaceChannel<Open>
        | Timeout of SubspaceChannel<Open>
        | ConnectionLost of SubspaceChannel<Failed>

pub op closeChannel =
    subject channel: SubspaceChannel<Open>
    outcomes =
        | Closed of SubspaceChannel<Closed>

send only accepts a SubspaceChannel<Open> and transitions it to Transmitting. While transmitting, you can't send another message — send requires Open, and you're holding Transmitting. You call awaitResponse, which returns the channel to Open on success or transitions to Failed on connection loss. The types enforce the async state flow: the compiler won't let you send on a channel that's still waiting for a reply, and it won't let you close a channel that's mid-transmission.

This is what I wanted: I/O where the compiler tracks the resource state your program is holding, and using that value in the wrong state is a type error rather than a runtime exception. The state machine is in the declaration, not in a developer's head — which means an agent working with the channel gets the same guardrails as a human.

From I/O to Workflows

I designed resources for I/O. What I didn't expect was how naturally the same mechanism models domain workflows.

Every significant entity on a starship has a lifecycle. An away mission is proposed, reviewed, approved, launched, and completed — or aborted. A repair order is filed, triaged, assigned, and resolved. A course change is plotted, verified, authorized, and executed. These aren't I/O resources, but they have the same structure: named states, valid transitions, operations that only make sense in certain states.

Most codebases model this with a status field and a runtime guard:

type MissionStatus =
    | Proposed
    | Approved
    | InProgress
    | Completed
    | Aborted

type Mission = {
    id: Guid
    name: String
    status: MissionStatus
    team: List<CrewMember>
    objective: String
}

let launchMission (mission: Mission) =
    if mission.status <> Approved then
        failwith "Can only launch approved missions"
    // ... proceed

The guard works. But the compiler doesn't know that launchMission requires an approved mission — it accepts any Mission. A developer who calls launchMission with a proposed mission gets a runtime failure, not a compile error. And there's nothing in the type that tells a reader — or an agent modifying the code — what the valid states and transitions are.

With resource, the mission lifecycle works like the subspace channel:

pub resource Mission =
    state Proposed
    state Approved
    state InProgress
    state Terminal
        state Completed
        state Aborted

Each state produces a different type. Mission<Proposed> and Mission<Approved> are as distinct to the compiler as String and Int. An operation that approves a mission only accepts the proposed state:

pub op approveMission =
    subject mission: Mission<Proposed>
    by captain: CrewMember
    outcomes =
        | Approved of Mission<Approved>
        | InsufficientIntelligence
        | CrewNotAvailable of missing: List<String>

Now try launching a mission that hasn't been approved:

launchMission proposedMission by riker
-- Compile error: launchMission expects Mission<Approved>, got Mission<Proposed>

Riker can't skip Picard's sign-off. Not because of a runtime check that someone might forget to add, but because the types don't permit it.

The `performs` Clause

The approveMission operation above constrains which state it accepts — only Mission<Proposed>. But it doesn't yet declare which state it produces. The performs clause makes the transition explicit:

pub op approveMission =
    subject mission: Mission<Proposed>
    by captain: CrewMember
    performs Mission.Proposed -> Mission.Approved
    outcomes =
        | Approved of Mission<Approved>
        | InsufficientIntelligence
        | CrewNotAvailable of missing: List<String>

The performs clause tells the compiler two things: this operation starts with the resource in Proposed state, and on success, transitions it to Approved. The compiler validates both directions. If performs says Proposed -> Approved but the success outcome carries Mission<InProgress>, that's a compile error. If the subject is typed as Mission<InProgress> but performs says Proposed -> Approved, that's also a compile error. Declaration and type must agree.

Not every operation performs a state transition. Read-only operations omit performs:

pub op getMissionBriefing =
    subject mission: Mission<Approved>
    outcomes =
        | Briefing of MissionBriefing

This requires a specific state — you can only get the briefing for an approved mission — without transitioning to a new state. The subject type still enforces the precondition.

The Full Mission Lifecycle

Here's the complete state machine with all operations declared:

pub resource Mission =
    state Proposed
    state Approved
    state InProgress
    state Terminal
        state Completed
        state Aborted

pub op proposeMission =
    payload objective: MissionObjective
    payload team: List<CrewMember>
    by officer: CrewMember
    outcomes =
        | Proposed of Mission<Proposed>
        | InvalidObjective of reason: String

pub op approveMission =
    subject mission: Mission<Proposed>
    by captain: CrewMember
    performs Mission.Proposed -> Mission.Approved
    outcomes =
        | Approved of Mission<Approved>
        | InsufficientIntelligence
        | CrewNotAvailable of missing: List<String>

pub op launchMission =
    subject mission: Mission<Approved>
    by firstOfficer: CrewMember
    performs Mission.Approved -> Mission.InProgress
    outcomes =
        | Launched of Mission<InProgress>
        | TransporterUnavailable
        | EnvironmentalHazard of hazard: String

pub op completeMission =
    subject mission: Mission<InProgress>
    performs Mission.InProgress -> Mission.Completed
    outcomes =
        | Completed of Mission<Completed>
        | ObjectivesIncomplete of remaining: List<String>

pub op abortMission =
    subject mission: Mission<InProgress>
    by officer: CrewMember
    performs Mission.InProgress -> Mission.Aborted
    outcomes =
        | Aborted of Mission<Aborted>

A pipeline that processes a mission through its lifecycle:

proposeMission objective team by riker
|> on Proposed mission ->
    approveMission mission by picard
    |> on Approved approved ->
        launchMission approved by riker
        |> on Launched active ->
            completeMission active
            |> on Completed done ->
                log $"Mission {done.name} completed successfully."
            |> on ObjectivesIncomplete remaining ->
                log $"Objectives remaining: {remaining}. Continuing mission."
        |> on TransporterUnavailable ->
            log "Transporter offline. Scheduling shuttle departure."
        |> on EnvironmentalHazard hazard ->
            log $"Launch aborted: {hazard}. Revising mission parameters."
    |> on InsufficientIntelligence ->
        log "Insufficient intelligence for mission approval. Requesting sensor sweep."
    |> on CrewNotAvailable missing ->
        log $"Required crew unavailable: {missing}."
|> on InvalidObjective reason ->
    log $"Mission objective rejected: {reason}."

The nesting mirrors the state progression. You can only enter the launchMission block with a Mission<Approved> because approveMission only produces one on its Approved arm. The types flow through the pipeline, and the compiler verifies every step. Each level handles its own outcomes completely — exhaustive handling from article 3 applies at every level.

Whole-Program State Machine Validation

The performs clauses across all operations define the state machine's transition graph. The compiler builds this graph and validates it for structural correctness.

Orphan state detection. A state is orphan if no operation transitions into it. If you declare a Suspended state on Mission but no performs clause has -> Mission.Suspended, the compiler warns: that state is unreachable. Either a performs clause is missing, the state is mislabeled, or it should be removed.

Dead-end state detection. A state is a dead-end if it has no outgoing transitions and isn't declared terminal. If Mission<Approved> had no operations with performs Mission.Approved -> ..., missions would get stuck — once approved, they could never progress. The compiler flags this.

Performs/subject consistency. Every performs From -> To clause must match its subject parameter type. If the subject is Mission<InProgress> but performs says Proposed -> Approved, the compiler rejects the mismatch.

Performs/outcome consistency. Every success outcome of an operation with performs From -> To must carry the resource typed as the target state. If performs says Proposed -> Approved but the outcome carries Mission<InProgress>, that's a compile error.

Together, these four checks make the state machine self-consistent and verifiable without running any code. The compiler catches the structural errors — orphan states, dead ends, mismatched transitions — that would otherwise surface as unreachable code paths, stuck entities, or confused runtime behavior in production.

Projections with State

Projections from the previous article interact naturally with typestate. A projection can require a specific state:

type MissionBriefing = Mission<Approved> only {
    name; objective; team; approvedBy; approvedAt
}

type MissionReport = Mission<Completed> only {
    name; objective; team; completedAt; findings
}

MissionBriefing can only be constructed from a Mission<Approved>. Passing a Mission<Proposed> is a type mismatch. MissionReport requires Mission<Completed>. The state requirement is encoded in the projection, not in a runtime check.

This addresses a subtle problem: some fields only have meaningful values in certain states. The approvedBy field on a mission is empty before approval. A projection that requires Mission<Approved> says, at the type level, that approval data is part of the value being projected. The findings field is empty before completion. A projection that requires Mission<Completed> says the same thing about mission findings.

What Compounds

A pattern has emerged across these articles. op started as a way to enforce error handling under schedule pressure; it turned out to produce exhaustive compiler verification. Projections started as DTO shorthand; they turned out to produce provable access boundaries. Resources started as a way to reason about I/O; they turned out to model enterprise workflows with compiler-verified state machines. Each feature was designed for practical relief and arrived at structural correctness.

What I didn't anticipate is how they compound. An op whose subject is a resource in a specific state, whose payload is a projection of that resource — that single declaration encodes what data the operation can see, what state the resource must be in, what transitions are valid, and what outcomes the caller must handle. The compiler verifies all of it. Runtime guards, permission filters, tests, and code review still matter, but they usually operate as separate practices. These language features are designed to compose inside one declaration.

The first article argued that agentic coding needs a three-party model: humans define intent, agents write implementations, compilers verify structure. This is where that model becomes concrete. An agent modifying the mission workflow doesn't need to discover the state machine by reading runtime guards scattered across the codebase. The resource declaration and performs clauses are the state machine — declarative, complete, and compiler-verified. An agent that tries to skip from Proposed directly to InProgress gets a compile error. The compiler is the third party — verifying structure that neither the human nor the agent needs to hold in working memory.

What's Next

Operations declare what can happen and what comes back. Projections control what each operation can see. Typestate controls when each operation can run. But real procedures chain multiple operations together, and when step five fails, steps one through four may need to be undone.

The next article introduces sagas — multi-step workflows where each forward step is declared alongside its compensation. If beaming an away team down succeeds but establishing contact fails, the team needs to be beamed back up. The saga declaration reads like a mission briefing: each step, what undoes it, and what happens when the sequence breaks.

Ruuk is in alpha. If these ideas resonate, give ruuk a spin; follow along on GitHub and weigh in on the discussions.

This article was created with the help of AI

"It Didn't Happen" vs. "It Couldn't Happen"

Mat Weiss — Thu, 04 Jun 2026 13:00:00 +0000

Ever notice this pattern: a core type exists — User, Order, ShipSystems — and then derived types fan out from it? Response DTOs, dashboard views, API contracts, audit records. Each is a subset of the source, maintained separately, with no compiler-visible relationship to the original.

I started designing projections because I was tired of writing DTOs. What I ended up with was a correctness feature I hadn't anticipated — and one that generation alone can't provide.

The Subset Problem

Consider a starship's operational systems. Engineering, Tactical, Medical, and Science all need access to ship status, but each department should see only what it needs. Two approaches are standard.

The first: write separate types for each view. EngineeringData with five fields, TacticalData with four, MedicalData with two. Each is a manual subset of ShipSystems, maintained independently. When ShipSystems gains a field, each subset type is unaffected — which is either correct or a silent omission, depending on whether the new field belonged in that view. GraphQL takes a different angle on the same problem — let the client declare which fields it wants — but the boundary usually lives in schema and resolver tooling, not as a compiler-tracked derivation from the source type.

The second: write a filter function that strips fields at runtime.

function getShipData(role: DepartmentRole): ShipData {
  const systems = repository.getCurrentStatus();
  switch (role) {
    case "engineering":
      return filterToEngineeringFields(systems);
    case "tactical":
      return filterToTacticalFields(systems);
    case "medical":
      return filterToMedicalFields(systems);
    case "science":
      return filterToScienceFields(systems);
  }
}

Both work. The manual types are safe but tedious — and they drift from the source type over time, with nothing connecting the two. The filter function is flexible but operates at runtime, where misconfiguration can be silent: a filter that returns weapons targeting data to Medical may produce no error, no warning, no signal that anything went wrong.

Some type systems get partway there. TypeScript's Pick<ShipSystems, 'hullIntegrity' | 'warpCorePower'> gives you a structural subset — an operation typed against it cannot access fields outside it. That's real, and it's better than a runtime filter. But Pick is passive: add a field to ShipSystems and every Pick that excludes it continues to compile silently. No decision was forced.

Every developer who has written a DTO has said it in their head: "ShipSystems, but only these five fields." The missing piece is derivation tracking — a compiler that knows which views were derived from which source types, and surfaces the effect of schema changes across all of them.

Projections

This is what I wanted — a way to say "this type, but only these fields" that the compiler tracks. Ruuk calls them projections: typed views of a record type that maintain a declared relationship to their source.

Start with the full ship systems record:

pub type ShipSystems = {
    hullIntegrity: Float
    shieldStrength: Float
    weaponsStatus: WeaponsStatus
    targetingData: TargetingData
    warpCorePower: Float
    auxiliaryPower: Float
    lifeSupportLevel: Float
    crewBiosigns: List<Biosign>
    sensorReadings: SensorData
    missionParameters: MissionBriefing
    navigationCourse: CourseData
    communicationsLog: List<CommEntry>
}

Now declare what each department can see:

type EngineeringView = ShipSystems only {
    hullIntegrity; warpCorePower; auxiliaryPower; lifeSupportLevel; shieldStrength
}

type TacticalView = ShipSystems only {
    shieldStrength; weaponsStatus; targetingData; sensorReadings
}

type MedicalView = ShipSystems only {
    crewBiosigns; lifeSupportLevel
}

type ScienceView = ShipSystems only {
    sensorReadings; navigationCourse
}

Each projection is a type. EngineeringView has five fields. targetingData is not one of them — not because a filter removes it at runtime, but because it was never part of EngineeringView. The type doesn't have the field. There's nothing to misconfigure.

The only operator names the fields to include; everything else is excluded. Ruuk also has without, which works the other direction — name the fields to exclude, include everything else:

type PublicShipStatus = ShipSystems without {
    targetingData; missionParameters; communicationsLog
}

The choice between only and without is about intent and maintenance. only is explicit: you get exactly these fields, nothing more. When ShipSystems gains a new field, an only projection doesn't include it — you've declared what you want. without is inclusive by default: you get everything except the named fields. When ShipSystems gains a field, a without projection includes it automatically. Both are valid; the right choice depends on whether the safer default is "exclude new fields until reviewed" or "include new fields unless sensitive."

Projections Meet Operations

This connects directly to op from the previous article. Projections work with any function, but combined with op, the access boundary becomes part of the operation's contract. The parameter type on an operation controls what that operation can see. An engineering diagnostic that takes an EngineeringView cannot access weapons targeting data — not by policy, by type:

pub op runDiagnostic =
    payload systems: EngineeringView
    by engineer: CrewMember
    outcomes =
        | DiagnosticComplete of DiagnosticReport
        | SystemDegraded of system: String
        | InsufficientPower

Writing systems.targetingData anywhere in this operation's implementation is a compile error. The field does not exist on EngineeringView. There is no filter to misconfigure and no log to reconstruct.

Medical operations see only medical data:

pub op assessCrewReadiness =
    payload systems: MedicalView
    by medic: CrewMember
    outcomes =
        | AllClear
        | CrewMembersUnfit of count: Int
        | LifeSupportCritical of level: Float

assessCrewReadiness takes a MedicalView. It can read crewBiosigns and lifeSupportLevel. It cannot read weaponsStatus, targetingData, or missionParameters. The constraint is in the type signature, enforced at every call site, visible to any reader. This matters for the three-party model: an agent generating the implementation body of assessCrewReadiness cannot access fields outside the projection, even accidentally. The compiler blocks it the same way it blocks a human who reaches for the wrong field.

What Happens When the Data Model Changes

This is where derivation tracking earns its keep.

Suppose the Enterprise gets a sensor upgrade, and ShipSystems gains a new field:

pub type ShipSystems = {
    -- ... existing fields ...
    subspaceFieldReadings: SubspaceData   -- new field
}

What happens to the projections?

For without-based projections like PublicShipStatus, the new field is included automatically — it wasn't in the exclusion list. If subspaceFieldReadings is sensitive, every view that uses without now needs review. But the compiler knows which projections were affected by the schema change, so the developer can inspect each one and decide whether the new field belongs in the exclusion list.

For only-based projections like EngineeringView, the new field is excluded automatically — it wasn't in the inclusion list. No accidental exposure. If Engineering should see subspace readings, someone adds it explicitly.

Either way, the question "which views can see this new field?" has a definitive, machine-readable answer. The compiler traces the derivation relationship from source type to every projection. No manual audit of filter functions. No hoping someone remembered to update the access layer.

Field Accounting

Projections handle narrowing — taking a type and producing something smaller. Going the other direction is where field accounting kicks in.

If you receive a CrewMember and need to produce a CrewRecord for the ship's database, the relationship between the two types is explicit:

type CrewRecord = CrewMember extending {
    assignedQuarters: String
    dutyShift: DutyShift
    boardingDate: StarDate
}

CrewRecord has all the fields of CrewMember plus three more. The extending keyword declares the derivation — same idea as only and without, but in the widening direction. Now the compiler requires you to account for every field difference when converting between them.

Ruuk's transform keyword defines a conversion between related types — a mapping function with compiler-verified field coverage:

pub transform toCrewRecord (member: CrewMember) (quarters: String)
                           (shift: DutyShift) (date: StarDate) : CrewRecord =
    { member with
        assignedQuarters = quarters
        dutyShift = shift
        boardingDate = date }

The compiler checks this. The transform body must supply those three — and it does. If you forgot boardingDate, the compiler tells you exactly which field is missing and that it came from the gap between CrewMember and CrewRecord.

This is the balance equation: fields from the source plus fields added in the body must equal the fields required in the output. The compiler verifies the equation. You verify the domain logic. The division of labor is clean.

The Stronger Answer

There's a consequence of all this that I didn't anticipate when I started designing projections.

At some point, someone asks: "can Engineering access classified mission parameters?" With manual subset types or runtime filters, answering that question takes work. You trace the type definition or check the filter function, verify the configuration was correct for the period in question, and conclude that access didn't happen. That's a real answer — but it's a statement about observed behavior, and it depends on every link in the verification chain being intact.

With projections, the answer is the source code itself. runDiagnostic takes an EngineeringView, declared as ShipSystems only { hullIntegrity; warpCorePower; auxiliaryPower; lifeSupportLevel; shieldStrength }. The field missionParameters is not in that list. Access is structurally impossible — not unobserved, but inexpressible.

That's a meaningfully different kind of answer. It holds for every execution of the code, past and future, regardless of who or what wrote the implementation — until someone changes the projection declaration, at which point the change appears in version control, goes through review, and is auditable in its own right.

This is the same arc as op. I designed op to enforce error handling commitments under schedule pressure; it turned out to produce exhaustive compiler verification. I designed projections to avoid writing DTOs; they turned out to produce provable access boundaries. In both cases, the practical motivation led somewhere I hadn't planned — the feature I built for convenience became the feature I kept for correctness.

What's Next

Projections control what an operation can see. The next article addresses when an operation can run.

A starship mission moves through stages: proposed, approved, in progress, completed. You shouldn't be able to launch a mission that hasn't been approved, and you shouldn't be able to approve a mission that's already in progress. Today, those constraints live in runtime guards — if mission.status != "approved" then throw. The compiler doesn't know about them, doesn't verify them, and doesn't prevent someone from calling the wrong operation at the wrong time.

Ruuk's resource keyword and typestate move the state machine into the type system. A Mission<Proposed> is a different type from a Mission<Approved>, and the operation that launches a mission only accepts the latter. The compiler catches the violation before the code runs.

Ruuk is in alpha. If these ideas resonate, give ruuk a spin; follow along on GitHub and weigh in on the discussions.

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 in alpha. If these ideas resonate, give ruuk a spin; 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 in alpha. If these ideas resonate, give ruuk a spin; 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 in alpha — the language is available to try, and the design is still evolving. If the ideas in this article resonate, give ruuk a spin; 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

When Step Five Fails, Undo Steps One Through Four

The Problem: Distributed Commitment

Sagas as Declarations

Automatic Compensation on Failure

What the Compiler Verifies

A Richer Example: Ship Repair Workflow

Sagas vs. Pipelines

What Sagas Complete

Series Conclusion

You Can't Launch What Hasn't Been Approved

A Subspace Channel

From I/O to Workflows

The performs Clause

The Full Mission Lifecycle

Whole-Program State Machine Validation

Projections with State

What Compounds

What's Next

"It Didn't Happen" vs. "It Couldn't Happen"

The Subset Problem

Projections

Projections Meet Operations

What Happens When the Data Model Changes

Field Accounting

The Stronger Answer

What's Next

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?

The `performs` Clause

Introducing `op`

Handling Outcomes with `|> on`

Progressive Development with `todo`

When to Use `op` vs `let`