From Spawn to FuturesUnordered: How Community Feedback Reshaped Our Async Design

The Setup

A few weeks ago, I published a proof-of-concept on Reddit: "Abstraction as Complement to Standardization." The core idea: avoid vendor lock-in not with more layers, but by building a thin trait abstraction directly on top of the Future standard that Tokio, Embassy and WASM all implement.

The post resonated — it hit #2 on r/rust. But the real value came afterward, in the comments.

The community didn't just validate the approach. They questioned a specific design decision and offered something cleaner. And now we're rethinking the whole thing.

The Original Design: Four Traits

The PoC proposed four traits composed into a generic Runtime:

• RuntimeAdapter — platform identity
• Spawn — task creation (the controversial one)
• TimeOps — clocks and sleep
• Logger — structured output

The setup was clean: portable code receives RuntimeContext<R> and uses typed accessors. Everything monomorphizes away at compile time. No vtables, no dynamic dispatch.

async fn heartbeat<R: Runtime>(ctx: RuntimeContext<R>) {
    let time = ctx.time();
    let log  = ctx.log();

    loop {
        time.sleep(time.secs(5)).await;
        log.info(&format!("alive"));
    }
}

But there were two trade-offs baked in:

Trade-off #1: Send + Sync Bounds Leak Into Single-Threaded Targets

The traits assumed the most demanding target (multi-threaded Tokio). Embassy and WASM needed scoped unsafe impl Send/Sync as a workaround — justified but inelegant.

Trade-off #2: Fighting Embassy's Philosophy

Embassy is idiomatic at full static declaration. Our Spawn trait forced dynamic behavior through a type-erased task pool with unsafe { Pin::new_unchecked(...) }.

type BoxedFuture = Box<dyn Future<Output = ()> + Send + 'static>;

#[embassy_executor::task(pool_size = TASK_POOL_SIZE)]
async fn generic_task_runner(mut future: BoxedFuture) {
    let pinned = unsafe { Pin::new_unchecked(&mut *future) };
    pinned.await;
}

The unsafe is sound. But it works against Embassy's design, not with it.

I noted both trade-offs in the post. I called them "not yet happy with." Then I published and watched the responses come in.

What the Community Found

Read the full Reddit thread here. The discussion is worth your time — people contributed genuinely thoughtful patterns.

But one insight kept surfacing, from multiple angles: Maybe Spawn shouldn't be a default.

The realization came from a simple observation: When does AimDB actually spawn tasks?

Only during database.build(). After initialization completes, no new tasks are spawned. The set of futures is fully determined by configuration, not runtime events.

That's a constraint we didn't design around. We carried the Spawn abstraction for all runtimes because it's needed on Tokio. But on Embassy and WASM, it's pure overhead. A workaround solving a non-problem.

What if we used a different primitive for that specific phase?

The Pivot: FuturesUnordered

FuturesUnordered from the futures crate is designed for exactly this: managing a dynamic set of heterogeneous futures without an executor-level spawn primitive.

let mut tasks = FuturesUnordered::new();
tasks.push(producer_loop(ctx.clone()));
tasks.push(consumer_task(ctx.clone()));
tasks.push(transform_forwarder(ctx.clone()));
// ...
while tasks.next().await.is_some() {}

What changes:

• ✅ No executor-level Spawn trait needed
• ✅ No 'static cliff forcing unsafe impl Send/Sync workarounds
• ✅ No type-erased boxing to fight Embassy's static nature
• ✅ Works identically on Tokio, Embassy, WASM
• ✅ Heterogeneous futures still boxed, but that's internal bookkeeping

The trade-off:

• You call database.run().await instead of spawning tasks and letting the executor find them
• But you get back: simpler trait bound, no unsafe, no platform-specific hacks

Why This Matters

This isn't about one design being "right" and another "wrong." It's about constraints shaping architecture.

We optimized for the general case (multi-core work-stealing on Tokio). Then we adapted that design to single-threaded targets by layering workarounds on top.

What if we'd started from: "What's the minimal, idiomatic way to drive tasks on each platform?" Then composed backward to the abstraction layer?

That's FuturesUnordered for Embassy. That's work-stealing executors for Tokio. Then the common abstraction lives at the interface, not buried inside.

The community's feedback wasn't "your design is wrong." It was: "You're solving a problem that exists only because of how you framed the solution." This is what I want to emphasize: the community made us think differently.

Not about the final implementation. That's TBD, but about how to think about cross-platform abstractions.

The anti-pattern we uncovered: Optimize for the richest platform, then add scoped workarounds for simpler ones.

The pattern to try: Start from the constraints of each platform. Build the abstraction at the interface layer where they meet.

It's a subtle shift. But it changes where you place the burden. Instead of Platform A imposing its model on Platforms B and C, each platform expresses its nature clearly and the abstraction is the minimal glue.

Next Steps

We're evaluating the FuturesUnordered pivot. If it works (and early signals suggest it does), we'll:

1. Update the runtime adapter trait bundle
2. Remove the unsafe impl Send/Sync scoping
3. Add database.run().await as the initialization API
4. Write up the design decision and rationale

But here's the key: None of this happens without the Reddit conversation.

Your Thoughts?

If you've built cross-platform abstractions in Rust, what's your instinct? Does starting from platform constraints instead of feature parity change how you'd approach it?

We're actively tracking this work here: GitHub Issue #88 — Reconsider Spawn as default in runtime adapter

If you want to follow the implementation, jump in with thoughts, or hit us with pattern suggestions you've seen work, that's the place.

This is the kind of thinking-in-public I want to keep doing.

---

Originally published on Reddit as "Abstraction as Complement to Standardization." This is a follow-up reflecting on how the community feedback shaped our thinking.