a continuation (.then composition)

You leave a coat at the dry cleaner and tell them, 'when it's done, text me and I'll come iron it and hang it up.' You are not standing at the counter waiting — you have left behind a description of what to do next. A continuation is exactly that: a piece of work registered to run after some other computation finishes, taking its result as input. The classic spelling is .then: future.then(next), meaning 'when this future is ready, run next on its value'.

Concretely, instead of blocking on future.get() and stalling the thread, you attach a callback. When the producer fulfils the shared state, the runtime invokes your continuation with the result — possibly on a worker thread, without anyone having sat idle waiting. Because .then itself returns a new future (for whatever the callback produces), you can chain: fetch(url).then(parse).then(render). Each link is a continuation that fires when the previous result is ready, building a pipeline of dependent steps that never blocks a thread between stages. The downside of raw callbacks — code that reads inside-out and 'callback hell' of deep nesting — is precisely what async/await was invented to hide; await is, underneath, just sugar that registers the rest of your function as a continuation.

Continuations matter because they are how asynchronous results compose without blocking. They are the operational meaning of 'do X, then with the answer do Y' on a single thread that stays busy. Two honest caveats: error handling needs its own path (typically a .catch or the continuation receives a result-or-error), or failures vanish silently; and you must be clear about which thread the continuation runs on — assuming it resumes on the original thread when the runtime actually runs it on a pool worker is a frequent source of data races and UI-thread bugs.