Future Or Promise

Prime #

874

Origin domain

Computer Science & Software Engineering

Subdomain

concurrency → Computer Science & Software Engineering

Aliases

Promise, Deferred Value

Core Idea

A first-class placeholder for a value that does not yet exist but is committed to be supplied later, with a small protocol: a producer holding fulfillment authority, a consumer attaching continuations or waiting, and a once-only state machine moving exactly once from pending to fulfilled or rejected. The sharpness lies in reifying the deferral itself as a passable, composable object.

How would you explain it like I'm…

The Claim Ticket

Imagine you order food and they hand you a numbered ticket instead. The ticket isn't ice cream yet, but it's a real thing you can hold, save, or give to a friend. When your order is ready, the ticket turns into ice cream, or, if they ran out, into a "sorry" note. A future is that ticket for something that isn't ready yet.

Answer Coming Later

A future, also called a promise, is a placeholder object you get right away for a value that doesn't exist yet but is promised to come later. You can hold it, pass it around, and plan what to do with it before the real value shows up, like a claim ticket. One side, the producer, is in charge of filling it in with a result or marking it as failed. The other side, the consumer, can either wait for it or leave instructions for when it's ready. It changes exactly once, from "still waiting" to either "done" or "failed," and then it stays that way.

Placeholder For a Value

A future (or promise) is a first-class placeholder for a value that doesn't exist yet but is committed to arrive later, along with a small protocol for who fills it, who waits on it, what happens if it fails, and how later steps attach. It has four parts: a placeholder object you can create, pass, and store before the value exists; a producer side with the authority to fulfill it with a value or reject it with a reason; a consumer side that can attach follow-up steps or block until it resolves; and a state machine that moves exactly once from pending to either fulfilled or rejected and then stays put. The sharp idea is that it reifies the deferral itself: the not-yet-available value becomes an actual thing you can name, pass around, combine with other futures, and reason about. That is also exactly what makes async/await work, since the future is the handle that await operates on. It is sharper than just 'getting the answer later,' because a future as such requires the deferred outcome to be a real, passable, inspectable object with explicit fulfillment authority, which is what separates it from a mere hope or expectation.

 

A future, or promise, is a first-class placeholder for a value that does not yet exist but is committed to be supplied later, together with a small protocol governing who fulfills it, who waits on it, what happens if it fails, and how downstream computations attach to it. The structural commitment has four components: a placeholder object that can be created, passed, stored, and reasoned about before the value exists; a producer side with authority to fulfill the placeholder with a value or reject it with a reason; a consumer side that can attach continuations or block until resolution; and a state machine through which the placeholder transitions exactly once from pending to either fulfilled or rejected, and stays there. The pattern's sharpness lies in reifying the deferral itself. Without a future, code depending on a not-yet-available value must block, poll, or tangle itself in callback inversion. With a future, the not-yet-available value becomes a thing: a referent that can be named, passed, composed with other futures (race, all, sequence), chained with downstream operations, inspected, and reasoned about in types. That same reification is what makes async/await work, since the future is the handle on which await operates. The pattern is sharper than mere deferred resolution: a future as such requires the deferred outcome to be a first-class object, passable, composable, inspectable, with explicit fulfillment authority, and that requirement is what separates a promise from a mere expectation or hope.

Broad Use

• Computer science: futures and promises in Java, JavaScript, Scala, Rust; async/await; reactive streams.
• Distributed systems: RPC return values, remote object references, an agreed consensus value seen from a participant.
• Finance: futures contracts (deliver at a fixed date and price), forwards, options as conditional futures.
• Commercial law: escrow accounts (the escrow holder as a producer with conditional authority), letters of credit, layaway.
• Civil contracts: pre-orders, reservations, lease-with-option-to-buy.
• Healthcare: surgical waitlists and organ-allocation queues — slot promises contingent on triage.
• Diplomacy: treaty commitments that fulfill at named conditions.

Clarity

Distinguishes a value from a handle on a future value, making "what if the producer never fulfills?" immediately askable, and surfaces the producer–consumer authority split that underlies many disputes mis-framed as content disputes.

Manages Complexity

Turns invisible temporal coupling into a manipulable object: who-waits-on-what is expressed as a written, composable dependency graph (wait-for-all, wait-for-first, chain-after) rather than tracked in the head.

Abstract Reasoning

Forces case-completeness over three outcomes — pending-forever, fulfilled, rejected — and licenses authority decomposition (who may fulfill, reject, timeout, cancel) and a composition algebra of then/all/race.

Knowledge Transfer

• Software → smart contracts: the explicit pending/fulfilled/rejected state machine was imported into on-chain settlement protocols.
• Commerce → cryptography: third-party-authority escrow was re-implemented as cryptographic timelocks and multi-party signing.
• Finance → software: centuries-old futures contracts supplied the conceptual base that programmatic reservation systems inherit.

Example

A JavaScript Promise from fetch(url) is a value returnable before the response exists; .then/.catch attach continuations, the runtime's network layer is the sole producer, and Promise.all([a,b,c]) composes the dependency graph into a written object.

Relationships to Other Primes

Parents (1) — more general patterns this builds on

• Future Or Promise is a kind of State and State Transition — The file: 'Not state_and_state_transition in general — a future has a CONSTRAINED state machine': a single irreversible transition pending -> fulfilled|rejected. A specialization of state_and_state_transition (general machines cycle/revisit).

Path to root: Future Or Promise → State and State Transition

Not to Be Confused With

• Future Or Promise is not Lazy Evaluation because lazy evaluation defers computation until a value is demanded (pull-driven), whereas a future reifies a deferred result whose producer drives fulfillment independently of when the consumer asks.
• Future Or Promise is not Optionality because optionality is the right-without-obligation to act later, whereas a future is a commitment to resolve exactly once.
• Future Or Promise is not a Commitment Device because a commitment device binds a future self's behaviour by removing options, whereas a future is a data-flow placeholder with no self-binding.