Rust Interview Questions and Answers

Ownership allows one owner, but graphs and shared state need more. Rust pushes the choice into types.

• Rc<T>: single-threaded reference counting. clone increments a count and creates another owner; not atomic.
• Arc<T>: atomic reference counting, safe to share across threads.
• RefCell<T>: runtime-checked interior mutability for one thread. Borrowing rules are enforced at runtime and violations panic.
• Mutex<T> and RwLock<T>: cross-thread interior mutability. Locking returns a guard and poisoning is tracked.

use std::rc::Rc;
use std::cell::RefCell;

let shared = Rc::new(RefCell::new(vec![1]));
let alias = Rc::clone(&shared);
alias.borrow_mut().push(2);

Combine Rc<RefCell<T>> for single-threaded shared mutation and Arc<Mutex<T>> across threads. Rc and RefCell are not Send, so the compiler prevents using them across threads. Use Rc::downgrade to create a Weak reference that breaks reference cycles which would otherwise leak.

An async fn returns a Future, a state machine that does nothing until polled. An executor such as Tokio drives it. .await yields control while the future is pending, so one thread can juggle many tasks.

async fn fetch(url: &str) -> reqwest::Result<String> {
    let body = reqwest::get(url).await?.text().await?;
    Ok(body)
}

Futures do not allocate an OS stack each, so they are far cheaper than threads and let you run very many concurrent operations. The cost is a runtime dependency you must choose and configure.

Send means a value can move across threads; Sync means it can be shared by reference. Futures spawned onto a multi-threaded runtime must be Send, which is why holding a non-Send value such as an Rc or a std::MutexGuard across an .await fails to compile. Use tokio::sync::Mutex in async code and run blocking work on spawn_blocking. 'static bounds on spawned futures catch borrowing mistakes early.