Systems engineering rests on accurate and concise mental models. Libraries, frameworks, or platforms come and go, but principles are forever
Join me at Monster Scale Summit
Quint is the specification language you've been looking for
quint-lang.org
I am wondering if Claude Code excels if a specification includes exhaustive pre and post conditions. Without stating how to implement a function, we can still rigorously specify what the function does
(example in Dafny)
My current mental model of coding with agents:
Human attention moves to the edges
This diagram captures the core thesis of A Note on Distributed Computing:
Distributed and non-distributed executions are fundamentally different beasts
Distribution fragments execution
Distributed System ≠ Distributed Execution
A distributed system is a collection of concurrent components that communicate by exchanging messages
A distributed execution is an execution that is distributed across those components
The dist sys is the stage for the dist exe
My advice for software engineers in 2026
Get into formal methods
Not to prove your system correct but to prove your thinking correct
One more condition (j < i + k) gives us bounded idempotence.
Think Kafka retention: a request is idempotent only as long as the system remembers the request
No-op in respect to state, the system can still generate a response. For example Stripe returns the same response as on the first application IIRC
Here you go
bsky.app/profile/domi...
Systems don't pause between retries
If action a was applied at step i, then replaying a at any future step j is a no-op
Idempotence is a property of traces
Will post a follow up in a bit. I’ll ping you
The mathematical definition of idempotence will fail you in production
Not this
Applying a request n times has no effect beyond the first application
But that
Applying a request n times, regardless of how the state has evolved in between applications, has no effect beyond the first application
Fun with Types: The Shape of Durable Executions
Haskell's type system is a great vehicle for formalizing
@resonatehqio.bsky.social 's core execution model, execute_until_blocked
The shape of the conversation between User Program, Worker, and Server just fell out of the type system
Property-based Testing and Deterministic Simulation Testing change how you think about invariants:
First you defend the invariants your system has. Then you design the invariants your system should have
Invariants become aspirational, not just defensive
Event-driven. One of the most used terms in software engineering but with no formal definition
I've looked. I've found nothing
Please drop papers
Vibe coding forces the question: Where do guarantees come from?!
Platform
Property P is certain. All valid programs have P
Think memory-safe Rust program
Application
Property P is possible. Some valid programs have P
Think memory-safe C program
Deterministic Simulation Testing turns vibe coding into verified coding
LLMs are great at writing code, but just like their human counterparts, they miss edge cases
DST doesn't
DST is the fitness function your coding agent needs to maximize
The @resonatehqio.bsky.social server is responsible for
• Coordination (incl scheduling)
• Supervision (incl recovery)
That is, the server is responsible for scheduling a distributed execution onto a distributed system and reschedule parts of the execution when parts of the system fail
Durable Executions, defined
A crash? An interruption.
A sleep? An interruption.
Same suspension. Same resumption. Same solution.
The full definition: 12 words.
The minimal implementation: 50 lines.
journal.resonatehq.io/p/durable-ex...
See the Write Last, Read First rule in action, in Lisbon, today at 6:00pm
Join Matklad and me for an evening of systems engineering
luma.com/7d47f4et
Durable Executions, defined
Every durable execution framework: write normal code, get fault tolerance. Yet nobody defines what normal code or fault tolerance are
The alternative: a rigorous definition, grounded in first principles, and a minimal implementation
Dropping today
In distributed systems, you can never know "what is", you can only know "what was"
Even in consensus, you never know the current value, you only know the value at an offset in the log
Every decision is made on a stale understanding of the world
Resonate's Distributed Async Await doesn't add events, event types, event logs, or complex replay machinery.
Resonate makes promises durable. That's it.
Distributed Async Await, @resonatehqio.bsky.social Durable Executions framework, rests on one mechanic:
skip-when-done
- Checkpoint before the function starts
- Checkpoint after the function returns
- On restart, skip what's done
Everything else follows from there
Dead simple
Join Matklad and me in Lisbon next week for an evening of systems engineering with @tigerbeetle.com and @resonatehqio.bsky.social
I will talk about Write Last, Read First: How to keep systems consistent without transactions
bsky.app/profile/tige...
Dijkstra argued against unconstrained goto, not goto itself:
The unbridled use of goto statements makes it terribly hard to find a meaningful set of coordinates in which to describe the process progress
Unconstrained Event-Driven Architecture is distributed goto
Today's GoTo is Event-Driven Architecture
(Read first. Yell later)
Why your code should crash more
Assertions seem extreme: they don't throw exceptions, they crash the process. Yet continuing after a violation is worse than crashing.
Shut it down. Enable assertions in production
dtornow.substack.com/p/assert-in-...
📝 Blogged: "Building a Durable Execution Engine With SQLite"
Exploring the fundamentals of DE, based on a minimal engine built from scratch, using #SQLite as an execution log, and modern #Java (👋 virtual threads).
👉https://www.morling.dev/blog/building-durable-execution-engine-with-sqlite/
