Drifting in the Void

Luke Green — Fri, 16 Oct 2026 06:43:13 +0000

You are drifting through an endless void, and your eyes meet nothing but the void. No stars, no comets, nothing. But you know there may be something far away. Or maybe your eyes have already met the eternal darkness. And it is just you.

You try to move your body. However, you have no control over where you are travelling. It is taking you somewhere, and you do not know where you are going. There is no point of reference to tell you whether you are moving at all. You feel as though you are moving, but there is nothing you can do.

This feeling closely resembles life. You take a moment and look around. You know there are things around you: opportunities, people, and things you enjoy. However, you are a person drifting in the void, someone who can move but cannot travel.

You want to be somewhere else, maybe with someone you care about. You want to start your own business, have stable finances, or achieve something else you wish for. But you cannot travel the space between you and those things. There is a universe between you and the things you wish for.

How unfortunate is it that the internet is filled with happy things? Everyone seems perfect and has the perfect life. Fair enough; maybe that is true. And you look at yourself and wish you were there.

A better question would be: What sets you apart from the people who seem to be doing well in life? What are you missing?

Imagine that, for one day, you could take over the body of someone you aspire to be, maybe a CEO, a senior engineer at a top company, or someone else. Do you think being in that person's body would also change how you feel?

I think most things exist in a kind of balance, which might involve charisma, knowledge, skills, power, or something else. If that balance is missing, things tend to unfold in the opposite way. You can be a senior engineer or an investor for a day. However, would you possess all the knowledge and everything else required to hold that position?

There are eight billion people. People are born with different privileges. Someone born in a developed country may have opportunities that someone born in a developing or underdeveloped country does not.

Being born into a wealthy household, having educated parents, a healthy family and community, quality education, good friends, and the influence of people who can guide you can all make a difference. There could be infinitely many versions of your life, shaped by the decisions you make: the friends you choose, the college or school you attend, and so on. And you would never know what kind of person you might have become if you had been born into a different society, country, or family.

As a human being, what are you supposed to do? How beautiful would it be if you could snap your fingers and be anywhere you wished to be? Or if you could simply change something about yourself, maybe a habit, your energy, your motivation, or something else. But life is nowhere near that easy. And it is not fair. Some people seem to get everything throughout their lives, while others spend their entire lives trying and still get nothing.

So, the question might be: What is the point of trying at all if, in the end, it means nothing? We can do all the beautiful things in life, and yet we all share the same destination: death.

What we do with the time we have is irrelevant to the universe, isn't it? It surprises me how unfazed the human species can be in the face of existence itself. Even if you are the president of a country or a scientist, the universe does not care about you. What you do in life is just a distraction from the truth, which is death itself. And that is the only truth.

If everything in life is irrelevant, then why not try to do the things we want? Either way, we are just passing time. Why not choose the things that make these distractions a little more comfortable or bearable?

Your plugin system couldn't replace plugins. So here's the transaction that you're missing.

Luke Green — Sun, 20 Sep 2026 02:32:36 +0000

What if an upgrade fails halfway through activating? The question would be: what is still running?

In most plugin systems, the answer is: none. And in registries, the common bug could be as follows:

// the old plugin is already gone before the new one exists
registry.set('storage', await next.setup());

If setup() throws, the old working value is destroyed, and the new one never arrives. Now, your host is missing a capability it had a millisecond ago. In a daemon, that's an outage, not an error.

This is the failure mode that matters most for systems which can't restart: long-running CLI daemons, editors, dev tools, and the new wave of AI-agent extension hosts, where shipping an upgrade should be routine, not a maintenance window.

Replacing a live plugin is a transaction

Moult treats it like one. A plugin is a versioned capability provider with an owned resource scope, and replacing it runs a protocol, not an assignment:

Setup runs in a private scope — the candidate builds itself while the old generation keeps serving.
Verify checks its provides and conflicts — staged capabilities stay invisible to observers until commit.
Commit swaps the active generation in a single atomic step.
Dispose tears down the old generation, resources released in reverse acquisition order (LIFO).

If anything fails before the commit, the candidate scope is disposed, and the failure stays invisible: the previous generation remains active and usable. Like a crab, the system only sheds its shell once the new one is ready.

~30 lines, zero downtime on failed upgrade

import { capability, createRuntime } from '@moult/runtime';

const storage = capability<{ get(k: string): string | undefined }>('storage', '1.0.0');
const runtime = createRuntime();

runtime.install({
  id: 'memory.storage', version: '1.0.0',
  provides: [{ capability: storage }],
  setup: (ctx) => {
    const map = new Map([['k', 'v1']]);
    ctx.provide(storage, { get: (k) => map.get(k) });
  },
});
await runtime.start('memory.storage');

// A broken replacement is rejected — and v1 keeps serving:
await runtime.replace({
  id: 'memory.storage', version: '2.0.0',
  provides: [{ capability: storage }],
  setup: () => { throw new Error('bug in the new version'); },
}).catch((e) => console.log(e.code)); // REPLACEMENT_FAILED

// Usable, not just active: a consumer installed after the failure
// still binds the old generation's value.
let seen: string | undefined;
runtime.install({
  id: 'reader', version: '1.0.0',
  requires: [{ capability: storage, range: '^1.0.0' }],
  setup: (ctx) => { seen = ctx.require(storage).get('k'); },
});
await runtime.start('reader');
console.log(seen); // 'v1' — the failed v2 never existed to readers

That is the entire guarantee, runnable: the rejection is a structured MoltError, and a consumer installed after the failure still reads v1's value usable, not just active.

There's a second half to "versioned capability provider" that the snippet hides: capabilities carry a semver version, consumers declare semver ranges, and each token declares whether it accepts exactly one provider or aggregates many (multiple: true). Resolution runs during preparation; a candidate whose requirements don't resolve fails before setup, so a version mismatch can never become visible either.

The guarantee is the test suite

It's what's enforced. Nine replacement transaction tests cover failed setup, failed validation, disposal ordering, and resource cleanup, on top of property-based and stress suites: 145 tests, each run under both Node and a DOM environment — 290 runs, all green. The 15 invariants are written down in docs/guarantees.md, and the repo's comparison harness runs the same failed-upgrade scenario against a naive registry, cordis, and Moult, publishing the raw numbers in demo/comparison/RESULTS.md:

Runner	Survives	Leaked
naive registry	no	102
cordis 4.0.0-rc.9	no	0
@moult/runtime 0.1.1	yes	0

Excerpt — the full table adds the blocked-stop diagnostic and the average-ms column.
(Their caveat, which I'll repeat: environment-specific evidence, not a performance promise.)

That safety isn't free: the whole benchmark scenario — install, one failed replace, and one hundred successful replaces — averages ~16ms against ~0.14ms for the naive registry (roughly ~0.16ms per replace in that environment, not ~16ms; scenario average, not per-call). You pay it per replace, never per capability read.

A note on the neighbours: HMR reloads modules, and Module Federation shares them. Both are code-delivery mechanisms — neither promises that an upgrade either fully applies or fully rolls back. Moult owns a different layer: the replacement transaction itself. And if you use Vite, @moult/vite routes module updates through the same replace path, so import/setup failures preserve the old generation and the bridge doesn't commit anything itself; the runtime's transaction does.

The honest limits, because a runtime that hides its limits can't be trusted with your uptime: Moult is not a sandbox — plugins are trusted code, and it governs lifecycle and capability visibility, not permissions. It's not a loader or bundler; there's no global registry. And v1 refuses to silently rebind dependents — replacing a provider with active dependents is rejected outright with a structured REPLACEMENT_FAILED error that names the dependent path, instead of quietly re-wiring them. Moult preserves service, not state: every generation gets a fresh scope, so in-memory handles don't migrate — React component state is explicitly not promised to survive replacement, and durable state belongs in a host-provided capability. The success path is just as strict: replaced fires before the old scope is disposed, old resources release in LIFO order, and if the old generation's disposal fails after commit, the failure is recorded and inspectable — the replacement stands; there is no rollback.

Around the runtime there's a small family: @moult/events (generation-scoped typed events), @moult/react (bindings for committed contributions), @moult/test (utilities for proving ownership, replacement, and leak behaviour), and @moult/vite (Vite HMR bindings that route module updates through the same transactional lifecycle).

Try breaking it

npm install @moult/runtime  # Node 22 or newer

Repo: github.com/neryva-lab/moult — if you have an upgrade scenario your system can't survive, open an issue with the repro. I'd genuinely like to see it fail.