Arc<Mutex>

Guides

Rust walkthroughs

← Back to all guides

What are the trade-offs between async_trait and native async fn in traits with Rust 2024 edition?

async_trait uses boxing to return Pin<Box<dyn Future>>, incurring heap allocation and dynamic dispatch overhead, while native async fn in traits (stabilized incrementally since Rust 1.75) enables statically-dispatched futures without boxing. The trade-off centers on performance versus compatibility: async_trait works on older Rust versions and enables trait object dispatch (dyn Trait), while native async fn in traits provides zero-cost abstraction for concrete types but has limitations with trait objects and requires careful Send bound management. Rust 2024's improvements make native async fn increasingly viable, but async_trait remains useful for dynamic dispatch scenarios and backward compatibility.

The async_trait Crate Approach

use async_trait::async_trait;
 
#[async_trait]
pub trait Database {
    async fn fetch_user(&self, id: u32) -> Result<User, Error>;
    async fn fetch_all_users(&self) -> Result<Vec<User>, Error>;
}
 
struct PostgresDatabase {
    connection_string: String,
}
 
#[async_trait]
impl Database for PostgresDatabase {
    async fn fetch_user(&self, id: u32) -> Result<User, Error> {
        // Implementation can use .await naturally
        let conn = connect(&self.connection_string).await?;
        let user = conn.query("SELECT * FROM users WHERE id = $1", &[id]).await?;
        Ok(user)
    }
    
    async fn fetch_all_users(&self) -> Result<Vec<User>, Error> {
        let conn = connect(&self.connection_string).await?;
        let users = conn.query("SELECT * FROM users", &[]).await?;
        Ok(users)
    }
}

async_trait transforms async methods into returning Pin<Box<dyn Future>>.

How async_trait Works Internally

// What you write with async_trait:
#[async_trait]
impl Database for PostgresDatabase {
    async fn fetch_user(&self, id: u32) -> Result<User, Error> {
        let conn = connect(&self.connection_string).await?;
        Ok(conn.query(...).await?)
    }
}
 
// What the macro expands to:
impl Database for PostgresDatabase {
    fn fetch_user<'life0, 'async_trait>(
        &'life0 self,
        id: u32,
    ) -> Pin<Box<dyn Future<Output = Result<User, Error>> + 'async_trait>>
    where
        'life0: 'async_trait,
        Self: 'async_trait,
    {
        Box::pin(async move {
            let conn = connect(&self.connection_string).await?;
            Ok(conn.query(...).await?)
        })
    }
}
 
// Key observations:
// 1. async fn becomes synchronous fn returning Pin<Box<dyn Future>>
// 2. Future is heap-allocated (Box::pin)
// 3. Lifetime elision handled explicitly
// 4. Works with trait objects (dyn Database)

The macro boxes every async method call, creating heap-allocated futures.

Native async fn in Traits

// Rust 1.75+ supports native async fn in traits:
pub trait Database {
    async fn fetch_user(&self, id: u32) -> Result<User, Error>;
    async fn fetch_all_users(&self) -> Result<Vec<User>, Error>;
}
 
struct PostgresDatabase {
    connection_string: String,
}
 
impl Database for PostgresDatabase {
    async fn fetch_user(&self, id: u32) -> Result<User, Error> {
        let conn = connect(&self.connection_string).await?;
        let user = conn.query("SELECT * FROM users WHERE id = $1", &[id]).await?;
        Ok(user)
    }
    
    async fn fetch_all_users(&self) -> Result<Vec<User>, Error> {
        let conn = connect(&self.connection_string).await?;
        let users = conn.query("SELECT * FROM users", &[]).await?;
        Ok(users)
    }
}
 
// No macro needed, no boxing!

Native async fn generates static futures without heap allocation.

Performance Comparison

use std::time::Instant;
 
// async_trait: Heap allocation on every call
// - Box::pin allocates on heap
// - Dynamic dispatch through vtable
// - Cache locality impact from pointer indirection
 
// Native async fn: Stack allocation
// - Future stored on stack (usually)
// - Static dispatch (monomorphization)
// - Better inlining opportunities
 
// Benchmark scenario (conceptual):
async fn benchmark_async_trait(db: &dyn Database) {
    for _ in 0..1000 {
        // Each call: heap allocation + vtable dispatch
        db.fetch_user(1).await.unwrap();
    }
}
 
async fn benchmark_native_async<T: Database>(db: &T) {
    for _ in 0..1000 {
        // Each call: static dispatch, potential stack allocation
        db.fetch_user(1).await.unwrap();
    }
}
 
// Native async fn is typically:
// - Faster for hot paths (no allocation overhead)
// - Better optimized by compiler
// - Lower memory fragmentation

Native async fn avoids allocation and dynamic dispatch overhead.

Send Bounds and Trait Objects

// The key challenge: async fn in traits and Send bounds
 
// With async_trait, Send is opt-in:
#[async_trait]
pub trait Database: Send + Sync {
    async fn fetch_user(&self, id: u32) -> Result<User, Error>;
}
 
// Or using async_trait's Send bound:
#[async_trait(?Send)]  // Not Send by default
pub trait LocalDatabase {
    async fn fetch_user(&self, id: u32) -> Result<User, Error>;
}
 
// Native async fn requires explicit Send bounds:
pub trait Database {
    // The returned Future may or may not be Send
    async fn fetch_user(&self, id: u32) -> Result<User, Error>;
}
 
// To require Send:
pub trait Database {
    fn fetch_user(&self, id: u32) 
        -> impl Future<Output = Result<User, Error>> + Send;
    
    // Or with the more explicit form:
    fn fetch_user(&self, id: u32) 
        -> impl Future<Output = Result<User, Error>> + Send + '_;
}
 
// Rust 2024 improves this with:
// - return_position_impl_trait_in_trait (RPITIT)
// - Better Send bound inference

Send bound management differs significantly between approaches.

Trait Object Support

// async_trait: Works with dyn Trait
#[async_trait]
pub trait Processor {
    async fn process(&self, data: &[u8]) -> Vec<u8>;
}
 
async fn use_dyn_trait(processors: &[Box<dyn Processor>]) {
    for processor in processors {
        let result = processor.process(&[]).await;  // Works!
    }
}
 
// Native async fn in traits: Does NOT support dyn Trait directly
pub trait Processor {
    async fn process(&self, data: &[u8]) -> Vec<u8>;
}
 
async fn use_dyn_trait_native(processors: &[Box<dyn Processor>]) {
    for processor in processors {
        // ERROR: cannot use `dyn Processor` with async fn in trait
        // The trait `Processor` is not object safe
        let result = processor.process(&[]).await;
    }
}
 
// To use trait objects with native async fn, you need explicit boxing:
pub trait Processor {
    fn process<'a>(&'a self, data: &'a [u8]) 
        -> std::pin::Pin<Box<dyn std::future::Future<Output = Vec<u8>> + 'a>>;
}
 
// This is essentially what async_trait does for you!

async_trait enables dyn Trait usage; native async fn does not by default.

When to Use async_trait

use async_trait::async_trait;
 
// Scenario 1: Need trait objects (dyn Trait)
#[async_trait]
pub trait Handler: Send + Sync {
    async fn handle(&self, request: Request) -> Response;
}
 
struct Router {
    handlers: Vec<Box<dyn Handler>>,  // Requires async_trait
}
 
// Scenario 2: Support older Rust versions (< 1.75)
// async_trait works on Rust 1.39+
 
// Scenario 3: Complex lifetime scenarios
// async_trait handles complex lifetime elision
 
// Scenario 4: Multiple trait bounds
#[async_trait]
pub trait Service: Send + Sync + 'static {
    async fn call(&self, req: Request) -> Result<Response, Error>;
}

Use async_trait for dynamic dispatch and backward compatibility.

When to Use Native async fn in Traits

// Scenario 1: Performance-critical paths
pub trait FastProcessor {
    async fn process(&self, data: &[u8]) -> Vec<u8>;
}
 
// No boxing overhead, inlining possible
 
// Scenario 2: Static dispatch (generics)
async fn process_all<T: FastProcessor>(processors: &[T], data: &[u8]) {
    for processor in processors {
        // Static dispatch, no vtable lookup
        let _ = processor.process(data).await;
    }
}
 
// Scenario 3: Modern Rust codebase (1.75+)
// No dependency on procedural macros
 
// Scenario 4: Want explicit Future control
pub trait Database {
    // Explicitly control Future bounds
    fn fetch_user(&self, id: u32) 
        -> impl Future<Output = Result<User, Error>> + Send;
}

Use native async fn for static dispatch and performance-critical code.

Migration from async_trait to Native

// Before: async_trait
#[async_trait]
pub trait Repository {
    async fn find(&self, id: u32) -> Result<Item, Error>;
    async fn save(&self, item: &Item) -> Result<(), Error>;
}
 
// After: Native async fn (Rust 1.75+)
pub trait Repository {
    async fn find(&self, id: u32) -> Result<Item, Error>;
    async fn save(&self, item: &Item) -> Result<(), Error>;
}
 
// But watch for:
// 1. Send bounds - native requires explicit handling
// 2. Trait objects - won't work without manual boxing
// 3. Lifetimes - may need explicit annotations
 
// Before with Send requirement:
#[async_trait]
pub trait Repository: Send + Sync {
    async fn find(&self, id: u32) -> Result<Item, Error>;
}
 
// After with Send requirement:
pub trait Repository: Send + Sync {
    fn find(&self, id: u32) 
        -> impl Future<Output = Result<Item, Error>> + Send;
    
    // Or use the async fn shorthand with implicit bounds
    // (Rust 2024 improves inference)
}
 
// Full migration pattern:
pub trait Repository {
    // For methods that need Send:
    fn find(&self, id: u32) 
        -> impl Future<Output = Result<Item, Error>> + Send;
    
    // For methods without Send requirement:
    async fn save(&self, item: &Item) -> Result<(), Error>;
}

Migration requires attention to Send bounds and trait object compatibility.

Send Bound Management

// Rust 2024 edition improves Send bound inference
 
// Pattern 1: All futures must be Send (for spawn)
pub trait AsyncService {
    // Return position impl trait with Send bound
    fn handle(&self, req: Request) 
        -> impl Future<Output = Response> + Send;
}
 
// Pattern 2: Mixed Send requirements
pub trait MixedService {
    // This async fn's future IS Send (if self: Send)
    async fn handle_send(&self, req: Request) -> Response;
    
    // This explicit form allows non-Send futures
    fn handle_maybe_send(&self, req: Request) 
        -> impl Future<Output = Response>;
}
 
// Pattern 3: Where clause for Send bounds
pub trait Database {
    type Error;
    
    async fn query(&self, sql: &str) -> Result<Rows, Self::Error>
    where
        Self::Error: Send;  // Constraint on associated type
}

Rust 2024's improvements make Send bound management more ergonomic.

Lifetime Handling Differences

use async_trait::async_trait;
 
// async_trait handles lifetime elision automatically
#[async_trait]
pub trait Cache {
    async fn get(&self, key: &str) -> Option<Vec<u8>>;
    async fn set(&self, key: &str, value: Vec<u8>);
}
 
// Native async fn may need explicit lifetimes
pub trait Cache {
    async fn get(&self, key: &str) -> Option<Vec<u8>>;
    async fn set(&self, key: &str, value: Vec<u8>);
}
 
// Complex lifetime scenario (works better with async_trait):
#[async_trait]
pub trait Complex {
    // async_trait handles the 'async_trait lifetime automatically
    async fn method<'a, 'b>(&'a self, data: &'b [u8]) -> &'a [u8];
}
 
// Native may require explicit lifetime annotation:
pub trait Complex {
    async fn method<'a, 'b>(&'a self, data: &'b [u8]) -> &'a [u8]
    where
        'b: 'a;  // May need additional constraints
}

async_trait handles complex lifetime scenarios more automatically.

Real-World Pattern: Hybrid Approach

// Some projects use both approaches:
 
// Public API trait (for dyn support)
#[async_trait]
pub trait Plugin: Send + Sync {
    async fn initialize(&mut self) -> Result<(), Error>;
    async fn process(&self, input: &[u8]) -> Result<Vec<u8>, Error>;
}
 
// Internal trait (for performance)
pub trait InternalProcessor {
    async fn process(&self, data: &[u8]) -> Vec<u8>;
}
 
// Plugin can use InternalProcessor internally
struct MyPlugin {
    processor: Box<dyn InternalProcessor>,  // Won't work!
    // Actually need async_trait for this
}
 
// Or use generics for internal traits:
struct MyFastPlugin<P> {
    processor: P,
}
 
impl<P: InternalProcessor> Plugin for MyFastPlugin<P> {
    // Bridge between async_trait and native async
}

A hybrid approach can balance compatibility and performance.

Error Messages Comparison

// async_trait error (before expansion):
// "trait methods cannot be async"
 
// Native async fn error (complex case):
// "the trait `Send` is not implemented for `impl Future<...>`"
// More specific but requires understanding impl Trait
 
// async_trait handles some complexity silently
// Native async fn surfaces more complexity to the user
 
// Example: Spawning async trait method
// async_trait:
#[async_trait]
pub trait SpawningService: Send {
    async fn run(&self) {
        tokio::spawn(async move {
            self.do_work().await;  // Error: `self` not Send
        });
    }
    
    async fn do_work(&self);
}
 
// Native: Similar issues but clearer error messages about what's not Send

Error messages differ in specificity and helpfulness.

Comparison Table

// Comprehensive comparison:
 
// | Feature              | async_trait        | Native async fn      |
// |----------------------|--------------------|-----------------------|
// | Min Rust version     | 1.39+              | 1.75+                 |
// | Trait objects (dyn)   | Yes                | No (without boxing)   |
// | Performance          | Boxing overhead    | Zero-cost             |
// | Send bounds          | Macro attribute    | Explicit/implicit     |
// | Lifetime handling    | Automatic          | May need annotation   |
// | Compile time         | Slower (macro)     | Faster                |
// | Dependencies         | async_trait crate  | None                  |
// | Complex lifetimes    | Handles well       | May need annotation   |
// | Binary size          | Larger (boxing)    | Smaller               |
// | Debug experience     | Macro expansion    | Native                |

Synthesis

Use async_trait when:

  • You need trait objects (dyn Trait)
  • Supporting older Rust versions (< 1.75)
  • Complex lifetime scenarios need automatic handling
  • Convenience outweighs performance

Use native async fn when:

  • You only need static dispatch (generics)
  • Performance matters (hot paths, no boxing)
  • Modern Rust (1.75+) is acceptable
  • You want explicit control over Future bounds

Rust 2024 improvements:

  • Better Send bound inference for async trait methods
  • Return position impl trait in trait (RPITIT) stabilized
  • More ergonomic async fn in traits without macro workarounds

Key trade-off: async_trait provides convenience and trait object support at the cost of heap allocation and dynamic dispatch. Native async fn provides zero-cost abstraction but requires explicit Send bound management and doesn't support trait objects without manual boxing. The performance difference is typically 5-15% in microbenchmarks but can be significant in hot paths with many calls. For library authors, consider providing both: a native async trait for static dispatch users, and a boxed wrapper or async_trait version for dynamic dispatch needs.