#Non-goals (v1)

Flux draws its boundary as deliberately as its feature set. This page catalogues what the language does not do in v1 — each entry a design choice with a rationale, a diagnostic or a disposition, and a pointer to the seam where the capability, or its bounded equivalent, actually lives. A non-goal here is never an oversight: the guarantees in The seven design pillars are bought precisely by refusing the patterns that would break them, and the plane rules that enforce the refusals are specified in The four planes & the firewall.

New here? Start with Guide §14 — What Flux deliberately doesn’t do →

#At a glance

Figure — the v1 boundary is a wall with named doors: each refusal stops at the wall and points to the designated seam where the capability lives instead.

#No free-running loops

Flux is total, not Turing-complete — a deliberate trade, not a limitation inherited from a weaker language. Windows, folds and loops all exist, but every bound is a compile-time constant under a fixed cap. A program that cannot state its bound is rejected with [ErrTotal] at compile time rather than killed by a timeout at runtime.

Totality here means unbounded over time, bounded per step: the synchronous-dataflow discipline of the Lustre/Esterel family. A Flux program runs indefinitely, advancing one step per data unit or per frame; what it may not do is loop without a stated bound inside a single step. In Flux’s client-side, reactive domain that trade is invisible — an unbounded inner loop there is not a lost capability but a hung tab, which is to say a bug the type system declines to compile.

The design weighs an opt-in unsafe escape hatch for a genuinely unbounded loop and turns it down by default: nothing in the standard catalogue needs one, and admitting it would trade away the totality guarantee the rest of this page is built on. It is on the record so the trade is visible, not because it is on a roadmap. See The seven design pillars and Guide §2 — Why Flux is built this way.

#No direct I/O from scripts

The language has no fetch, no DOM, no eval, no file handles — no I/O primitives at all. Effects are host-mediated: a script emits inert command data under a declared capability, and the host executes it. A script can therefore ask for nothing it was not granted, and an artifact carries an inspectable, transitively aggregated manifest of everything it may request, visible before installation. This is what turns running an untrusted binary into a routine act rather than a risk assessment. The capability catalogue and the manifest are owned by FDK — Host services.

#Bar-centric time grain

The ANALYSIS clock advances on closed data units — the bar. Tick-level and order-flow granularity live in a separately named extension whose rollout follows v1, not an implicit promise of the bar-grain clock. ANALYSIS code written against the bar grain keeps its no-repaint guarantee precisely because a unit is closed before the graph ever sees it.

#External non-price data stays out of ANALYSIS

Network-fed data enters through the APP plane, as typed subscriptions, and can never silently become an indicator. The metric kind names the seam through which a causal external stream could enter ANALYSIS: the design carries that name and holds it inert, so admitting such a stream later needs no change to the grammar or the kind lattice. The kind that defines that seam is owned by Spec — Kinds.

#No market-wide scan, no portfolio management

Cross-series work over a handful of named instruments is first-class. Scanning the entire market, and managing many simultaneous positions, are not v1 concerns. A bounded screener — a total function mapped over a fixed-capacity universe with a keyed top-K — is a sealed pillar whose rollout follows v1: a bounded map-reduce, never an unbounded scan.

#No automatic code migration

Flux ships no converter from other script ecosystems. Its semantics deliberately exclude patterns some ecosystems permit — retroactive history edits, unbounded loops, ambient I/O — so a faithful automatic translation is impossible for a whole class of programs. The documentation teaches the equivalent Flux patterns directly instead.

#Sealed, and delivered after v1

Strategy backtesting harnesses, remote alert delivery and multi-device sync are sealed designs whose rollout follows v1; local alerts (alert) are v1. The public sharing and marketplace rollout follows v1 as well — while the trust model that makes it safe is v1 and is not weakened anywhere. The server-side subscription and replay machinery these build on is owned by FDK — Server.

#See also

• Guide §1 — What is Flux? — the narrative these limits close.
• The seven design pillars — the guarantees each refusal buys.
• The four planes & the firewall — the rules that enforce them.
• FDK — Host services — capabilities and the host-mediated effect boundary.
• FDK — Server — the subscription and replay surface behind the capabilities delivered after v1.
• Spec — Kinds — the metric seam and the kind system.