Learn Rust Advanced: Unsafe, Async & Metaprogramming

Q: What are the chances my unsafe code has UB?

Very high if you’re new to unsafe. Use Miri (cargo miri) and sanitizers to detect undefined behavior.

Rust Advanced: Unsafe, Async & Metaprogramming

DodaTech Updated Jun 20, 2026 7 min read

Rust’s safety guarantees are its killer feature — but real-world systems sometimes require bypassing the borrow checker for FFI, hardware access, or performance optimization. Understanding unsafe Rust, async/await internals, and macros separates intermediate Rust developers from experts.

In this tutorial, you’ll master unsafe Rust and FFI, async/await mechanics with Pin, declarative and procedural macros, trait objects (dyn vs impl), and advanced lifetime patterns.

What You’ll Learn

Unsafe Rust: raw pointers, unsafe traits, FFI
Async/await: Futures, Waker, Pin, executor internals
Macros: declarative (macro_rules!) and procedural (custom derive, attribute)
Trait objects: dyn dispatch, impl Trait, object safety
Advanced lifetimes: variance, higher-ranked trait bounds (HRTB)

Why Advanced Rust Matters

Systems programming in Rust requires understanding tradeoffs: when unsafe is necessary, how async actually works, and when to use dyn vs impl. At DodaTech, Durga Antivirus Pro uses unsafe FFI for signature scanning and async for concurrent file analysis.

Learning Path

    flowchart LR
  A[Rust Basics] --> B[Rust Advanced<br/>You are here]
  B --> C[Unsafe & FFI]
  B --> D[Async Runtimes]
  style B fill:#f90,color:#fff

Unsafe Rust

Unsafe Rust gives you five superpowers:

// 1. Dereference a raw pointer
let mut num = 5;
let r1 = &num as *const i32;
let r2 = &mut num as *mut i32;

unsafe {
    println!("r1 is: {}", *r1);
    println!("r2 is: {}", *r2);
}

// 2. Call an unsafe function
unsafe fn dangerous() {}

unsafe {
    dangerous();
}

// 3. Access mutable static
static mut COUNTER: u32 = 0;

unsafe {
    COUNTER += 1;
}

// 4. Implement unsafe trait
unsafe trait Foo {}
unsafe impl Foo for i32 {}

// 5. Access fields of unions
union IntOrFloat {
    i: i32,
    f: f32,
}

Expected behavior: Unsafe blocks opt into operations the compiler can’t verify. The rest of Rust’s safety rules still apply — only the five listed operations bypass checks.

FFI — Calling C from Rust

use std::ffi::CString;
use std::os::raw::c_char;

// Declare external C function
extern "C" {
    fn strlen(s: *const c_char) -> usize;
    fn puts(s: *const c_char) -> i32;
}

fn main() {
    let rust_string = "Hello from Rust!";
    let c_string = CString::new(rust_string).unwrap();

    unsafe {
        let len = strlen(c_string.as_ptr());
        println!("C string length: {}", len);

        puts(c_string.as_ptr());
    }
}

# Cargo.toml — use build.rs for complex FFI
[build-dependencies]
cc = "1.0"

Expected behavior: Rust calls C’s strlen and puts functions directly. The CString ensures null-terminated strings. The unsafe block acknowledges the FFI boundary.

Async/await Mechanics

Rust’s async is zero-cost — no allocations, no hidden runtime. But understanding Pin, Futures, and Waker is essential:

use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};

struct Delay {
    message: String,
}

impl Future for Delay {
    type Output = String;

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        // Simulate checking if work is done
        // In a real executor, you'd register the Waker
        Poll::Ready(self.message.clone())
    }
}

async fn example() -> String {
    let future = Delay { message: "done".to_string() };
    future.await
}

// Under the hood, the compiler generates a state machine:
// enum ExampleStateMachine {
//     Start,
//     Waiting(Delay),
//     Done,
// }

Expected behavior: The Future trait has one method: poll. When the executor calls poll, the future returns either Poll::Ready(value) or Poll::Pending. Pin ensures the future isn’t moved in memory (references to self must remain valid).

Declarative Macros (macro_rules!)

// vec! macro is defined using macro_rules!
macro_rules! my_vec {
    ( $( $x:expr ),* ) => {
        {
            let mut temp_vec = Vec::new();
            $(
                temp_vec.push($x);
            )*
            temp_vec
        }
    };
}

let v = my_vec![1, 2, 3]; // Expands to push 1, 2, 3

// Match expressions
macro_rules! calculate {
    (eval $e:expr) => {
        {
            let val: usize = $e;
            println!("{} = {}", stringify!($e), val);
            val
        }
    };
}

calculate!(eval 1 + 2); // Prints "1 + 2 = 3"

Procedural Macros

Procedural macros operate on the token stream at compile time:

// Custom derive — in a separate crate
use proc_macro::TokenStream;
use quote::quote;
use syn::{parse_macro_input, DeriveInput};

#[proc_macro_derive(HelloMacro)]
pub fn hello_macro_derive(input: TokenStream) -> TokenStream {
    let ast = parse_macro_input!(input as DeriveInput);
    let name = &ast.ident;

    let gen = quote! {
        impl HelloMacro for #name {
            fn hello_macro() {
                println!("Hello, Macro! My name is {}", stringify!(#name));
            }
        }
    };
    gen.into()
}

// Usage
#[derive(HelloMacro)]
struct Pancakes;

Pancakes::hello_macro(); // "Hello, Macro! My name is Pancakes"

Trait Objects: dyn vs impl

// impl Trait — static dispatch (monomorphization)
fn notify_impl(item: &impl Notification) {
    item.send();
}
// Compiles to separate function per concrete type

// dyn Trait — dynamic dispatch (vtable)
fn notify_dyn(item: &dyn Notification) {
    item.send();
}
// One function, dispatch via vtable pointer

// When to use which:
// - impl: performance-critical, few call sites
// - dyn: heterogeneous collections, plugin systems

// Object safety — not all traits can be dyn
// No: Sized, Clone (returns Self), methods with type params
// Yes: Iterator, Read, Write, most single-method traits

Expected behavior: Static dispatch is faster (direct call) but increases binary size (monomorphization). Dynamic dispatch is flexible but has a vtable lookup cost.

Advanced Lifetime Patterns

// Higher-Ranked Trait Bounds (HRTB)
// "for any lifetime 'a, F must work"
fn call_with_ref<F>(f: F)
where
    F: for<'a> Fn(&'a str) -> &'a str,
{
    let s = "hello";
    println!("{}", f(s));
}

// Variance
struct Covariant<'a>(&'a str);    // &'a T is covariant in 'a
struct Invariant<'a>(Cell<&'a str>); // Cell<T> is invariant

// Subtyping example
fn longer<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

Common Mistakes

1. Using unsafe When Safe Alternatives Exist

Most unsafe code is unnecessary. Use Cell, RefCell, Mutex, or RwLock before reaching for raw pointers.

2. Forgetting Pin Requirements for Self-Referential Structs

Async blocks may create self-referential structs. Always return Pin<Box<dyn Future>> or use pin_mut! for stacking futures.

3. Overusing Box Instead of Generics

Each dyn Trait call goes through a vtable. For hot paths, use generics with impl Trait for static dispatch.

4. Writing Macros When a Function Would Do

Macros increase compile time and make code harder to debug. Start with a function, refactor to a macro only if you must.

5. Ignoring the Drop Check

Rust’s drop check ensures no references to memory that’s being dropped. Use #[may_dangle] carefully.

6. Not Using Pin<Box> for Self-Referential Types

Self-referential types (e.g., a struct with a pointer to another field) require Pin. These are rare — prefer owning all data.

Practice Questions

1. What five operations does unsafe allow?

Dereference raw pointer, call unsafe function, access mutable static, implement unsafe trait, access union fields.

2. What does Pin guarantee?

Pin guarantees that the value won’t be moved in memory. Required for self-referential types like async state machines.

3. What’s the difference between impl Trait and dyn Trait?

impl uses static dispatch (monomorphization). dyn uses dynamic dispatch (vtable). impl is faster; dyn is more flexible.

4. What is a procedural macro?

A function that takes a TokenStream and returns a TokenStream, executed at compile time. Used for custom derive, attribute, and function-like macros.

5. Challenge: Build a minimal async executor.

Implement a simple executor that polls futures. Use a channel to wake futures when they’re ready.

Mini Project: FFI Binding to libcurl

use std::ffi::CString;

#[link(name = "curl")]
extern "C" {
    fn curl_easy_init() -> *mut std::ffi::c_void;
    fn curl_easy_setopt(handle: *mut std::ffi::c_void,
        option: u32, value: ...) -> u32;
    fn curl_easy_perform(handle: *mut std::ffi::c_void) -> u32;
    fn curl_easy_cleanup(handle: *mut std::ffi::c_void);
}

const CURLOPT_URL: u32 = 10002;

fn fetch(url: &str) {
    unsafe {
        let handle = curl_easy_init();
        let c_url = CString::new(url).unwrap();
        curl_easy_setopt(handle, CURLOPT_URL, c_url.as_ptr());
        curl_easy_perform(handle);
        curl_easy_cleanup(handle);
    }
}

FAQ

When should I use unsafe Rust?

Only when you need to dereference raw pointers, call FFI, or implement a data structure the borrow checker can’t verify. Wrap unsafe in safe abstractions.

Does Rust have a standard async runtime?

No. Tokio is the de facto standard. The standard library provides the Future trait and task system; the ecosystem provides executors.

What are the chances my unsafe code has UB?

Very high if you’re new to unsafe. Use Miri (cargo miri) and sanitizers to detect undefined behavior.

What’s Next

Go Advanced