Comparison to alternatives

CX and Python — the standard to meet and exceed

Python is not what CX sets out to replace. It is the standard CX measures itself against: readable on day one, batteries included, as good for a ten-line script as for a system. CX is built to meet that standard and to go past it where data work hurts. Each claim below stands beside a conformance case this guide's cx replayed when the page was built.

Exact numbers by default. In Python a fraction is a binary float until you import decimal. In CX a fraction literal is an exact base-10 decimal, and arithmetic keeps it one:

        [?let [= $subtotal 19.99] [= $shipping 5.01] [total [+ $subtotal $shipping]]]
      

        $ cx prog.cx
[total 25.00]
      

Mixing a decimal with a binary float is refused out loud, naming the one bridge between them, rather than rounded in silence:

        [+ 1.5 1.0e0]
      

        $ cx prog.cx
[err code=cx-err:CXER0100 message='+: decimal/bigint arithmetic admits only int/bigint/decimal operands — [cast] is the only decimal↔float bridge (L44)' at='1:1']
      

Effects are granted, never inherited. A Python script can read every file its process can. A CX program reads nothing until you grant it, and the refusal is an ordinary value that names the flag which would allow it:

        [?lib 'cx-stdlib/io']
[$io:read-file "/var/log/app.log"]
      

        $ cx prog.cx
[err code=cx-err:CXER0271 message='E_CAP_DENIED: read capability required for io-read-file; none granted (grant via --allow-read)' at='2:1']
      

Regular expressions that do not backtrack. Python's re is a backtracking engine. CX's re is RE2: a construct that would need backtracking, such as a backreference, is refused when the pattern compiles:

        [?lib 'cx-stdlib/re']
[$re:compile "(.)\\1"]
      

        $ cx prog.cx
[err code=cx-err:CXER3200 message='E_RE_FEATURE_UNSUPPORTED: CXER3200:E_RE_FEATURE_UNSUPPORTED: (.)\1' at='2:1']
      

Errors are values. An error flows out of anything built from it, so a failure is a value you can inspect where it surfaces, not an exception unwinding past you:

        [?let [= $e [err code='c' message='m']] [report $e]]
      

        $ cx prog.cx
[err code=c message=m]
      

Updates never mutate. [?modify] answers a new document; the one it started from is unchanged:

        [users [user name=Alice]]
      

        [?let [= $orig $doc] [= $new [?modify $doc //user/@name [set "Bob"]]] [pair orig=$orig/user@name new=$new/user@name]]
      

        $ cx --data=input.cx prog.cx
[pair orig=Alice new=Bob]
      

One value model for every format. JSON parses into the same values the language computes with, and a map is a map whatever order its entries were written in:

        [?lib 'cx-stdlib/json']
[$json:parse "{\"a\": 1}"]
      

        $ cx prog.cx
{a: 1}
      

        [?let [= $z 0] ([= {a: 1, b: 2} {b: 2, a: 1}], [= {a: 1, b: 2} {a: 1, b: 3}], [= {a: 1} {a: 1, b: 2}])]
      

        $ cx prog.cx
(true, false, false)
      

Identity is built in. A value's SHA-256 is taken over its canonical bytes, so the same value written two ways hashes alike:

        [$eq [$cx:hash [$cx:parse "[a   1]"]] [$cx:hash [a 1]]]
      

        $ cx prog.cx
true
      

When to reach for CX

CX is the default for data, config and interchange. The specialists further down this list are the cases where one layer is the whole problem. Top to bottom, first match wins:

• You need one syntax for data and code (config that is also a program, templates that are also data, a schema that is also a value). CX is the only format in this comparison that is homoiconic; pick CX.
• You need content-addressable identity across languages and platforms (cache keys, dedup, signed documents, distributed ledgers). The CX SHA-256 of canonical bytes is the most boring possible implementation; pick CX.
• You round-trip between JSON / YAML / TOML / XML / Markdown and lose information each time. CX is the superset that preserves all of them losslessly; pick CX.
• Your workload is bulk analytical scan on tabular data at terabyte scale, exchanged with the broader ecosystem (DuckDB / Spark / pandas). Use Parquet for storage, Arrow for in-memory, optionally with CX as the metadata / config layer.
• Your workload is wire-format throughput between microservices with a fixed schema, and you control both ends. Use Protocol Buffers or MessagePack — they will be smaller and faster on the wire than any text format.
• You need a single-file human-edited config with no programmability and no cross-system identity requirements. TOML (Cargo, pyproject) or YAML (Kubernetes, CI) are everywhere; the ecosystem advantage is real.
• You need a typed, programmable config language with a strong type system. Dhall or Pkl are good fits if the type-system rigor matters more than the homoiconic data-and-code unification.
• Otherwise (general data / config / interchange with mixed workloads, mid-size documents, multiple consumers in different languages): CX is the all-purpose default.

CX vs JSON

JSON is the universal interchange baseline. CX is a superset projection — anything that round-trips through JSON also round-trips through CX. The interesting comparisons are where CX has features JSON does not, and where JSON has ecosystem JSON does not.

When to pick JSON instead of CX. Your consumers are browser JavaScript, a CDN-served config endpoint, or any interface where you cannot install a CX parser. JSON remains the right wire-format choice for ubiquity alone.

When to pick CX instead of JSON. You want identity, schema, comments, mixed content, dates, or bytes without layering JSON Schema + JSON5 + base64 + custom date string conventions on top of JSON. CX gives you the whole stack in one syntax.

CX vs YAML

YAML optimises for human readability of multi-line strings and config-as-code. The cost is the famously large surface area (indentation sensitivity, tag system, anchor / alias / merge keys, the Norway problem).

When to pick YAML. Your config consumers are Kubernetes manifests, Ansible playbooks, GitHub Actions workflows, or any tool whose schema is in YAML. The ecosystem advantage is decisive.

When to pick CX. Anywhere you would have wanted YAML minus the indentation footguns, the Norway problem, and the lossy round-trip. The triple-quoted multiline string is as readable as YAML literal blocks without the indentation rules.

CX vs TOML

TOML's pitch is "obviously correct config for configuration files." It excels at flat key-value configs (Cargo.toml, pyproject.toml) and struggles with deep nesting.

When to pick TOML. Your config is flat — language toolchain manifests, Cargo dependencies, app configuration with two levels of nesting. TOML reads beautifully at that scale.

When to pick CX. Your config is genuinely hierarchical, you need cross-config identity, or the same documents will also be processed as data (e.g. shipped as configuration and hashed for a release manifest). CX scales up where TOML hits its ceiling.

CX vs XML

XML is CX's closest structural cousin — both are tree-shaped, both support attributes and mixed content, both have namespaces. The differences are syntactic density and the surrounding ecosystem (XSLT, XPath, XSD).

When to pick XML. You are working in publishing / document workflows (DITA, DocBook, SVG), or your consumers are XML-native (SOAP, XHTML, RDF/XML). The tooling depth is unmatched in those niches.

When to pick CX. You want the XML data model (attributes, mixed content, namespaces, XPath) without the syntactic verbosity, without XSD, and with code-as- data unification. CX is what XML would look like if designed today.

CX vs Protocol Buffers

Protobuf is the schema-first binary wire format for service-to-service traffic. It is the right tool when you control both ends, the schema rarely changes, and every byte on the wire matters.

When to pick Protobuf. You have a controlled RPC system, the schema is well-understood, and the bandwidth / CPU savings are real (mobile, embedded, hot-path services). Honest concession: Protobuf wins on wire throughput in the steady state.

When to pick CX. Your data is also config, also logs, also human-edited at the boundary, also stored on disk for later inspection. Protobuf loses to text formats outside the wire-only path.

CX vs MessagePack

MessagePack is "binary JSON" — schemaless, more compact than text JSON, slightly slower than protobuf because it carries kind tags.

When to pick MessagePack. You want JSON semantics on the wire without JSON wire size, and your data is flat / tabular / homogeneous. MessagePack is excellent at being "JSON minus the text.".

When to pick CX. Your data has shape — attributes, mixed content, namespaces, hierarchical structure that MessagePack would force into nested maps. data-bin covers the wire-size argument without giving up the shape.

CX vs Apache Pkl

Pkl is Apple's configuration language — declarative, strongly typed, programmable. The closest "config that is also code" peer to CX, with a different design centre.

When to pick Pkl. You want a strongly typed config language with class-oriented composition and your consumers are JSON / YAML output. Pkl's type system is richer than the CX schema language.

When to pick CX. The same documents are also data to be hashed, queried, transformed, or shipped as payloads. Pkl is config-first; CX is data-and-code by design.

CX vs Dhall

Dhall is the typed-config purist's pick — total, non-Turing-complete, with a sound type system and normalised import semantics.

When to pick Dhall. You want totality, soundness, and a small surface area as design goals; you are willing to pay for the steeper learning curve. Dhall is the right tool for safety-critical config.

When to pick CX. You want the content-addressed identity, the schema-validated config, and the programmable updates of Dhall — plus the ability to carry rich data (mixed content, columnar tables, dates, bytes) in the same syntax. Dhall is config; CX is config + data + code.

CX vs Parquet

Parquet is the columnar storage standard for analytical workloads — terabyte-scale scans, predicate pushdown, compression. CX is not Parquet's competitor; CXCol is, and Parquet is CX's export target.

When to pick Parquet. Your data is large, tabular, queried by external tools (Spark / Athena / BigQuery / DuckDB), and stored on object storage. Parquet is the lingua franca.

When to pick CXCol. Your data is tabular but the producers and consumers are CX-native (pipelines, in- memory analytical workloads, services that ship columnar payloads). When you need to interchange with the broader ecosystem, export to Parquet.

CX vs Arrow

Arrow is the in-memory columnar standard. Like MessagePack, it is not a CX competitor — it is a layer CX integrates with.

When to pick Arrow. You are doing pure analytics — no document semantics, no identity requirements, no schema as a value. Arrow is the right cross-engine in-memory layout.

When to pick CXCol over Arrow. You want Arrow's column-orientation plus CX's document semantics (mixed content rows, hierarchical headers, namespaced columns, hash-stable identity). Use the bridge — they share memory zero-copy.

Summary table

At a glance, the headline trade-offs for each alternative. Pick CX is the column that matters most for an evaluator question.

CX's case, in one paragraph. CX wins on unification: the document, the transform, the value model and the identity are one syntax — cx-vs-python shows each, replayed: the update that leaves its original unchanged, JSON arriving as a CX map, the hash over canonical bytes. Where one layer IS the whole problem — a browser-only JSON consumer, a Kubernetes manifest, a terabyte Parquet scan — reach for the specialist, and read its format into CX where the rest of the system lives. Everywhere else, CX is the default.

If you have a workload that does not match any row of this table or §13.1's decision tree, file an issue at https://github.com/cx-home/cx — the comparison is maintained as a living document; new alternatives and new use-case scenarios are added as the ecosystem evolves.

At-a-glance feature matrix

One-screen feature matrix across CX, JSON, YAML, TOML, and XML. The per-format children (§13.2-§13.11) carry the depth; this matrix is the spreadsheet view.

Conversion-loss matrix

Lossless conversion means the data round-trips without semantic loss; presentation details (comments, whitespace, attribute order) may be normalized. The table below is the honest accounting of what survives, what gets normalized, and what is genuinely lossy.

Presentation-layer differences — comments (only XML and CX preserve them; JSON has none; YAML and TOML lose them through most parsers), whitespace (normalised to the target conventions), attribute order (emission may pick a canonical order), anchor names (canonical form renumbers them). These all show up as identical hashes via cx hash because the hash operates on strict-canonical bytes, where presentation is stripped.

Where CX is fast — measured

CX's performance culture is gates, not brags: every number below names its runner, was measured on the reference dev machine (Apple Silicon, -prod build, 2026-08-20), and is re-measured each release. Claims without a measurement do not ship in these docs.

When CX wins

Every alternative on this page does one layer. CX wins when the layers are the problem. A real system is data plus a schema plus a query language plus a transform layer plus config plus a wire format plus, increasingly, an agent interface — and the incumbent answer is seven tools with six impedance boundaries between them: JSON with JSON Schema bolted on, jq for queries, a template engine for transforms, YAML for config, protobuf for the wire, and a hand-written tool layer for the agents.

CX is one surface for the whole stack. The same bracket form is the document, the schema that validates it, the query that selects from it, the transform that rewrites it, the config that deploys it, and the program that serves it — [?match] and [?modify] operate on the same values cx hash addresses. Identity is machine-checked, not promised: strict canonical bytes give every value one SHA-256 address on every platform and every binding, which is what makes caching, dedup, signing, and content-addressed storage boring instead of bespoke. Adoption is ring-scoped: take the data format alone (it cannot execute anything), and nothing above it can reach down and make it heavier. The runtime is compiled native — the numbers above, from one binary with no interpreter tax. And the same definitions that serve humans serve agents at parity: the tools face and the ux projection derive from the identical [?def]s, so an agent interface is something you already have, not something you build.

Reach for a specialist when one layer IS the whole problem — §13.1 names those cases. Reach for CX when you would otherwise be gluing the specialists together.