Rust Developer interview prep

Short answer: Traits give interface-style polymorphism — with default methods and blanket impls. A supertrait is an obligation to "also implement that trait," not inheritance of fields and behavior. Code reuse in Rust is built on composition: you embed a type in a struct and delegate (including via Deref).

In depth:

1. Polymorphism — a shared interface via trait + default methods; statically (generics) or dynamically (dyn).
2. Blanket impl — impl<T: Display> ToString for T gives ToString to every Display type at once — reuse without a hierarchy.
3. Supertrait ≠ inheritance — trait B: A requires implementing A too, but doesn't inherit its state; it's a constraint, not "is-a."
4. Composition — component fields + method delegation replace class chains; "has-a" instead of "is-a."

⚠️ Common mistake: calling a supertrait "inheritance." It drags along no fields or implementation — it's just a requirement to implement another trait.

Short answer: Box<T> is a single owner — a plain heap allocation with zero-cost dereference. Rc<T> is shared ownership via a non-atomic reference count, single-threaded only. Arc<T> is the same shared ownership, but the count is updated atomically, so it can be shared across threads (at the cost of atomic operations).

In depth:

1. Box<T> — one owner, no counter. Use it when a value must live on the heap: recursive structures, trait objects (Box<dyn Trait>), large values. Dereference is free.
2. Rc<T> — several owners in one thread. clone() increments the strong count, drop decrements it; data is freed when it hits zero. Hands out only &T — put a RefCell inside for mutation.
3. Arc<T> — like Rc, but the count lives in atomics (fetch_add/fetch_sub). Implements Send/Sync, fit for multithreading; wrap in Mutex/RwLock to mutate.

⚠️ Common mistake: reaching for Arc everywhere "just in case". If there's a single owner, Box or even the stack is enough; Arc's atomic operations aren't free, and in one thread they're pure overhead.

Short answer: Option<T> — when a value may simply be absent and the reason doesn't matter (Some/None). Result<T, E> — when an operation can fail and the caller needs the cause (Ok/Err).

In depth:

1. Option — models "the value may not be there": HashMap::get missed the key, Vec::first on an empty vector. None carries no reason.
2. Result — models "the operation failed": File::open didn't find the file, str::parse couldn't parse. Err(e) explains what went wrong.
3. Conversion — they cross over easily: option.ok_or(err) turns None into Err, and result.ok() drops the error and yields an Option.

⚠️ Common mistake: returning Result where absence is normal (or Option where the caller needs the cause). "Key not found" is an Option, not an error.

Short answer: Send means ownership of a value can be safely moved to another thread; Sync means &T can be safely shared across threads (by definition T: Sync ⇔ &T: Send). These are auto traits: the compiler implements them structurally — a type is Send/Sync if all its fields are. You write nothing by hand.

In depth:

1. Structural derivation — the auto trait propagates through fields: a struct of Send fields is itself Send. Raw pointers (*const T, *mut T) deliberately opt out of both, which strips the traits from types built on them.
2. unsafe impl — if you uphold thread safety manually (e.g. wrapping a raw pointer in correct synchronization), you may write unsafe impl Send for MyType {}. That's an assertion you're responsible for: the compiler can't check it.
3. Opting out explicitly — a negative impl (impl !Send for T) is nightly-only; that's how Rc is marked inside std. On stable you strip the trait with a marker field like PhantomData<*const ()> (!Send + !Sync).

⚠️ Common mistake: thinking Send and Sync are about a type's "thread-safety in general". Send is about moving ownership between threads, Sync about shared access via a reference; these are distinct guarantees, and a type can have one without the other.

Short answer: A Future is a lazy state machine implementing the Future trait with a poll method. Calling an async fn doesn't start work — it only constructs the future value. The code inside runs only when an executor polls it, i.e. when you .await it or hand it to spawn.

In depth:

1. async fn returns a value — a type impl Future<Output = T>. The call is a state-machine constructor, not the start of the computation.
2. Laziness — unlike a thread, a future does not spin in the background on its own. Until something polls it, it's inert.
3. Who drives the future — an .await inside another async function, or tokio::spawn, which hands the task to the runtime. Without that, the work never begins.

async fn work() { println!("running"); }

let fut = work(); // nothing happened — no print
fut.await;        // only now the body actually runs

⚠️ Common mistake: expecting an async fn to start "like a thread" the moment you call it. A forgotten .await is work that never ran — and often an unused_must_use warning: "futures do nothing unless you .await or poll them."