asupersync Rebuilding the Floor Everyone Stands On

01 · What it is

What an async runtime is, and why this one exists

Every networked program faces the same arithmetic: thousands of connections, one machine. Spawning a thread per connection burns memory and drowns the scheduler, so modern servers use an async runtime. That is the machinery that juggles thousands of waiting I/O operations across a handful of threads, parking tasks while they wait and waking them when data arrives. In Rust, that machinery is almost always tokio: the most widely used async runtime in the ecosystem, the default in every tutorial, the foundation under hyper, axum, and reqwest.

asupersync is a from-scratch alternative to tokio (written fresh, not forked), and it is the foundation of the entire FrankenSuite constellation: the one repo in the program that isn't a "franken" rewrite of something else, but the floor the other forty-odd projects stand on.

The pain it targets is real and underappreciated: a cancelled task leaves partial effects behind; a detached task outlives its owner; shutdown is best-effort: the process exits "eventually," maybe; the worst bugs reproduce under one schedule and vanish under a debugger. asupersync's bet is that this class of bugs should be removed by construction. Task ownership and cancellation become structural, not left to programmer discipline.

02 · Why build it

Why build a new runtime from scratch?

The maintainer, Jeffrey Emanuel, a solo developer building the whole suite, gives the case explicitly in the project's README. A tokio fork could never deliver it, because the API is deliberately incompatible: asupersync "trades implicit convenience for explicit cancel-correctness" and is "not a drop-in replacement for other runtimes: different API, different guarantees." The guarantees are structural: every task is owned by a region that closes to quiescence; cancellation is an explicit request → drain → finalize protocol with budgeted bounds; runtime effects flow through explicit capability tokens, so a task can't touch what it wasn't granted. Rust is the medium because its compiler rules out whole classes of memory bugs at build time. That is the same safety argument that underwrites the rest of the suite.

There is a counter-case, and the assessment surfaced it from several directions at once. First, tokio owns the lane: the most widely used Rust async runtime, with years of production hardening, a vast ecosystem, and the "nobody got fired for choosing tokio" default. Second, no competitor bothers with structural cancel-correctness, which is another way of saying no buyer currently selects a runtime on cancellation semantics. That is the unproven bet at the heart of the project. Third, the family's own flagship is a hostile witness: frankenredis evaluated asupersync in April 2026 and rejected it as an architectural substrate, choosing a hand-rolled I/O loop instead. And fourth, adoption is entirely captive: the reverse-dependency list and every observable workload sit inside the maintainer's own constellation. So the headline download count measures family consumption, not market conversion.

03 · What was built

What the project actually built

The scale is startling for one person: about 3.86 million lines of Rust across 4,709 files, though the analyst cautions that 533 files with "test" in the name physically live in src/, so the "2.27M-line runtime" figure overstates the shipped library; the publish list strips tests to stay under crates.io's 10 MB cap. Six subsystems each exceed 100,000 lines: networking, the runtime core, observability, a deterministic lab runtime, a QUIC-native transport stack, and messaging. Around the core scheduler (a three-lane design that prioritizes cancellation over timers over ready work) sit epoll with optional io_uring on Linux, SQLite/PostgreSQL/MySQL clients, HTTP/1.1 and HTTP/2, partial HTTP/3, TLS, WebSocket, Kafka, actor supervision, a tokio-compat bridge, and a WASM browser edition. One crate is several projects wearing a trench coat.

The evidence machinery is the interesting part:

• A README that scopes what it can't prove. The 2,626-line README carries an status table marking HTTP/3, WebSocket conformance, and the formal-methods work as partial, with prose explaining exactly what is missing. Cancellation budgets are labeled "sufficient conditions only." Non-cooperative work can still delay quiescence indefinitely.
• Gates instead of headlines. The project publishes almost no speedup claims. Instead it publishes the gate: a CI-blocking baseline that fails any substantive change above max(5%, the recorded ci95 envelope, +0.6ns) versus 105 committed baselines, with "intentionally no [skip ci]-style waiver."
• Unsafe code under census. deny(unsafe_code) at the crate root, with 47 named allow islands (platform probes, cpuid), each scoped and auditable.
• It actually ships. Twenty GitHub releases with signed multi-platform builds; version 0.5.0 on crates.io with 318,241 downloads and 78 reverse-dependency crate versions. frankensqlite runs its storage I/O on asupersync with capability tokens in its public APIs; frankensearch mandates it and forbids tokio in its own manifests.

04 · Where it stands

Where it stands

In our program's terms: TRL 6, NODUS ring Pilot. In plain English: it ships, it's installed from the registry, and real workloads inside the constellation run on it. But no one outside the maintainer's orbit has qualified it, the API is deliberately incompatible with the incumbent, and one person holds the whole thing.

What would change the verdict, in order

Until then, the rational posture is the assessment's: mine it for methodology, keep shipping tokio.

05 · What it teaches

What this teaches about building with agents

The transferable lesson is the inverse of frankenredis's disavowed benchmark table. frankenredis published numbers and then disavowed them; asupersync publishes almost no numbers at all. source source It publishes the gate that would catch the numbers being wrong. The CI-blocking baseline with no waiver, the README that scopes what it can't prove, the budgets labeled "sufficient conditions only": this is evidence infrastructure built for an agent-built world, where output volume is cheap and trust is the scarce good. Don't publish benchmark numbers. Publish the machinery that would catch you lying about them.

But the tagline episode is the sharper half of the lesson. The maintainer's own 2,626-line README never claimed RDMA or netlink support. source The ecosystem's marketing shorthand outran its most careful writer. Honesty that lives only in prose is fragile: it rots with velocity and gets misquoted by your own tagline. The fix is the one the assessment proposes: machine-checked claim discipline — claim text → code artifact → status row, verified in CI — so the next tagline can't outrun the tree. Don't write honest documentation. Build the machinery that keeps the documentation honest.