Top 30 Rust Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   When evaluating a new cloud infrastructure project, which statement accurately reflects the trade-off between using Rust versus Go?

   • aRust provides deterministic latency and compile-time data-race safety at the cost of a steeper learning curve, whereas Go trades runtime GC overhead for simplicity and faster onboarding.
   • bGo's garbage collector automatically prevents all concurrent data races, making it safer than Rust for multi-threaded code without extra developer effort.
   • cRust is always faster in every workload and eliminates the need for synchronization primitives, while Go's GC makes it unsuitable for high-performance systems.
   • dRust's ownership model is strictly superior for all projects regardless of team size, while Go's GC makes it impossible to achieve predictable tail latency.
   Show the answer

   Answer: a · Rust provides deterministic latency and compile-time data-race safety at the cost of a steeper learning curve, whereas Go trades runtime GC overhead for simplicity and faster onboarding.

   B is correct because it accurately pairs Rust's deterministic, zero-cost memory safety and compile-time data-race prevention with its steeper learning curve, while recognizing Go's GC introduces runtime overhead in exchange for simplicity and faster onboarding. C is a tempting distractor because Go does automate memory reclamation, but its GC does not prevent data races—memory safety and concurrency safety are distinct, and Go leaves more thread-safety responsibility to the developer.

   Read the full bite: Compare Go's GC and Rust's ownership across performance, productivity, and safety

2. Question 2 of 30

   What is a key advantage of Rust's philosophy of bundling its official documentation with the language installation?

   • aIt enforces a standardized development environment across all Rust projects.
   • bIt streamlines the process for contributing new features to the Rust language itself.
   • cIt guarantees developers have immediate, offline access to comprehensive learning materials.
   • dIt significantly reduces the initial download size of the Rust toolchain.
   Show the answer

   Answer: c · It guarantees developers have immediate, offline access to comprehensive learning materials.

   The card states that bundling the documentation ensures every user has immediate, offline access to a high-quality learning resource. Option D is incorrect because documentation adds to the download size, it doesn't reduce it.

   Read the full bite: Rust's Philosophy: Documentation and Community First

3. Question 3 of 30

   You add a new variant to an error type during a large refactor. Why does Rust typically surface every place needing an update more reliably than Go?

   • aGo's compiler treats every unhandled error as a fatal build error
   • bGo does not support custom error types so the change cannot compile
   • cRust automatically rewrites all call sites for you
   • dRust's exhaustive match makes non-updated handling sites fail to compile
   Show the answer

   Answer: d · Rust's exhaustive match makes non-updated handling sites fail to compile

   Adding an enum variant makes existing exhaustive matches incomplete, so Rust's compiler flags each site. Go's error values do not force callers to branch, so it does not flag missed sites; Rust does not auto-rewrite code.

   Read the full bite: Refactoring under Go simplicity versus Rust correctness

4. Question 4 of 30

   When a developer wants to abstract over a third-party type, which difference between Go interfaces and Rust traits is most significant?

   • aGo requires the third-party type's author to explicitly declare interface satisfaction, while Rust traits are satisfied automatically by matching method signatures.
   • bRust allows any consumer crate to implement a foreign trait for a foreign type without modification, making it more loosely coupled than Go.
   • cGo interfaces use nominal typing checked only at compile time with no runtime overhead, whereas Rust dyn Trait relies on runtime type information.
   • dGo lets a consumer define an interface that the third-party type implicitly satisfies, while Rust requires an explicit impl block to bind the trait to the type.
   Show the answer

   Answer: d · Go lets a consumer define an interface that the third-party type implicitly satisfies, while Rust requires an explicit impl block to bind the trait to the type.

   Go uses structural typing, so a consumer can define an interface that an existing third-party type automatically satisfies without any declaration; Rust uses nominal typing, requiring an explicit impl block. Distractor A reverses these exact mechanics, reflecting the common misconceptions that Go needs explicit declarations and that Rust traits are implicit.

   Read the full bite: Compare Go interfaces with Rust traits

5. Question 5 of 30

   Which statement accurately contrasts the safety responsibilities you assume when using unsafe in Rust versus Go?

   • aBoth languages disable their primary safety mechanisms entirely, differing only in whether a GC is present
   • bRust's borrow checker still enforces rules on safe code and only five superpowers bypass checks, while Go requires guaranteeing GC reachability and valid memory
   • cRust allows aliasing mutable references without restriction inside unsafe blocks, while Go prevents pointer arithmetic entirely
   • dRust's borrow checker is fully disabled within unsafe blocks, while Go relies on the compiler to track GC roots automatically
   Show the answer

   Answer: b · Rust's borrow checker still enforces rules on safe code and only five superpowers bypass checks, while Go requires guaranteeing GC reachability and valid memory

   Rust's borrow checker continues enforcing rules on safe code inside unsafe blocks; only the five superpowers bypass checks, while Go unsafe requires manual cooperation with the GC to ensure reachability and valid memory. Distractor A is wrong because the borrow checker is not fully disabled, and D is wrong because Rust still requires upholding aliasing invariants and Go unsafe enables pointer arithmetic.

   Read the full bite: Contrast unsafe in Go versus Rust and the invariants you assume

6. Question 6 of 30

   If you write let x = 5 in Rust and x := 5 in Go, which statement about mutability is correct?

   • aBoth allow reassignment, but Rust requires the mut keyword only when reassigning the value
   • bBoth declarations create immutable bindings by default
   • cThe Rust declaration is immutable, while the Go declaration allows reassignment without extra keywords
   • dIn Go, var creates an immutable binding, while the short declaration operator creates a mutable one
   Show the answer

   Answer: c · The Rust declaration is immutable, while the Go declaration allows reassignment without extra keywords

   Rust makes bindings immutable by default, so let x = 5 cannot be reassigned without let mut, while Go variables declared with := or var are mutable by default. Option D is a common misconception because both var and := create mutable bindings in Go, and true immutability requires const.

   Read the full bite: How does Go's variable declaration and mutability differ from Rust?

7. Question 7 of 30

   What is the main mechanical difference between Go's for i := 1; i <= 5; i++ and Rust's for i in 1..=5?

   • aGo uses a C-style control statement that manually manages the index, while Rust consumes an iterator hiding index management.
   • bGo requires parentheses around the three clauses, while Rust's 1..=5 range is exclusive on the upper bound.
   • cGo's for keyword is reserved for numeric loops, while Rust requires the loop variable to be declared mut to iterate.
   • dThe two loops are semantically identical statement-based constructs and differ only in surface syntax.
   Show the answer

   Answer: a · Go uses a C-style control statement that manually manages the index, while Rust consumes an iterator hiding index management.

   Go's for is a control statement with explicit initialization, condition, and increment, whereas Rust's for consumes an iterator produced by the inclusive range. Option D is a tempting distractor because both loops look similar, but claiming they are semantically identical misses the statement-driven versus iterator-based gap.

   Read the full bite: Write a 1-to-5 loop in Go and Rust

8. Question 8 of 30

   Which accurately describes a key difference between Go's switch and Rust's match?

   • aGo switch can return a value directly to initialize a variable, while Rust match arms must end with an explicit break to prevent fallthrough.
   • bGo switch implicitly falls through and requires explicit break, while Rust match requires exhaustive patterns but allows fallthrough between arms.
   • cBoth Go switch and Rust match enforce exhaustiveness at compile time, but only Go allows implicit fallthrough for multiple case values.
   • dRust match is an expression that yields a value and requires exhaustive patterns, while Go switch is a statement with implicit breaks and no exhaustiveness check.
   Show the answer

   Answer: d · Rust match is an expression that yields a value and requires exhaustive patterns, while Go switch is a statement with implicit breaks and no exhaustiveness check.

   Rust match evaluates to a uniform value and the compiler rejects non-exhaustive patterns, whereas Go switch is statement-oriented, auto-breaks, and never checks exhaustiveness. Option B is tempting but wrong because Go implicitly breaks unless fallthrough is explicit, and Rust match arms never fall through.

   Read the full bite: Compare Go's switch with Rust's match on exhaustiveness, fallthrough, and expressions.

9. Question 9 of 30

   What is the immediate consequence when ownership of a variable is moved to a function in Rust?

   • aThe original variable becomes invalid and cannot be accessed further.
   • bThe variable's memory is deallocated as soon as the move operation completes.
   • cThe function receives a temporary, immutable reference to the variable's data.
   • dA new, independent copy of the variable's data is created for the function.
   Show the answer

   Answer: a · The original variable becomes invalid and cannot be accessed further.

   When ownership is moved, the original variable is invalidated, as the card states 'Once you've given it away, it's no longer yours to use' and the example demonstrates a compile error for subsequent use. Option D is incorrect because for complex types like String, ownership is moved, not copied, unless explicitly cloned. Option B is incorrect because the memory is freed when the new owner (the function's parameter) goes out of scope, not immediately upon the move.

   Read the full bite: Rust Ownership: Memory Safety Without a Garbage Collector

10. Question 10 of 30

    When passing a string to a function by value, why is Go's operation cheap while Rust's String may require explicit cloning?

    • aRust &str is an owned growable buffer that allocates on every function call, while Go strings are fat pointers that share mutable heap data.
    • bBoth languages copy the entire heap buffer on pass-by-value, but Go's garbage collector makes the operation appear cheaper.
    • cGo strings are small two-word headers copied by value with immutable backing data, whereas Rust String moves ownership and must be cloned to duplicate its heap buffer.
    • dGo strings use copy-on-write reference counting, while Rust String always performs a deep copy when passed by value.
    Show the answer

    Answer: c · Go strings are small two-word headers copied by value with immutable backing data, whereas Rust String moves ownership and must be cloned to duplicate its heap buffer.

    Go strings are small two-word headers (pointer and length) that are cheaply copied by value while remaining immutable, whereas a Rust String owns its heap buffer and moves ownership by default, so duplicating it requires an explicit clone. Option D is tempting because copy-on-write is common in other languages, but Rust String is uniquely owned and Go strings do not use reference counting.

    Read the full bite: Compare Go string and Rust &str/String types, mutability, UTF-8, ownership

11. Question 11 of 30

    Which scenario correctly describes a fundamental rule enforced by Rust's borrow checker for memory safety?

    • aYou can have either one mutable reference or any number of immutable references to data, but not both simultaneously.
    • bMemory is automatically freed by a runtime garbage collector when data goes out of scope.
    • cA value must always have at least two owners to prevent accidental deletion.
    • dMultiple mutable references to the same data are allowed as long as they are in different functions.
    Show the answer

    Answer: a · You can have either one mutable reference or any number of immutable references to data, but not both simultaneously.

    The borrow checker enforces that you can have either one mutable reference OR multiple immutable references to a piece of data at any given time, but never both, preventing data races. Option D is incorrect because the borrow checker strictly disallows multiple mutable references to the same data concurrently, regardless of the function scope.

    Read the full bite: Rust's Borrow Checker: Memory Safety at Compile Time

12. Question 12 of 30

    What happens if a caller ignores the error when parsing a string to an integer in Go versus Rust?

    • aGo issues a compiler warning because the error return is must-use, while Rust allows silent ignoring since Result is only idiomatic
    • bBoth panic at runtime if parsing fails because unhandled explicit errors escalate to panics in both languages
    • cBoth compile without issue because neither language requires the caller to handle an explicit error value
    • dGo compiles silently because error checking is purely conventional, while Rust emits a must-use warning since Result is enforced by the type system
    Show the answer

    Answer: d · Go compiles silently because error checking is purely conventional, while Rust emits a must-use warning since Result is enforced by the type system

    Go relies on programmer discipline to check the second error return value, so ignored errors compile silently. Rust's Result is must-use, so the compiler warns if it is not handled via match or ?; distractor A reverses these roles.

    Read the full bite: Parse a string to integer in Go and Rust with errors

13. Question 13 of 30

    What is the primary benefit of defining a Rust trait, such as Summary with a summarize method, and implementing it for multiple distinct types?

    • aIt enforces that all implementing types must have the exact same internal data structure to support the summarize method.
    • bIt allows writing generic functions that can operate on any type that fulfills the Summary contract, promoting code reuse.
    • cIt enables types to inherit data fields and state directly from the trait definition, similar to class inheritance.
    • dIt automatically provides a default implementation for the summarize method if one is not explicitly defined by the implementing type.
    Show the answer

    Answer: b · It allows writing generic functions that can operate on any type that fulfills the Summary contract, promoting code reuse.

    The card states traits enable "writing generic functions that can accept any type that fulfills a certain contract," which directly leads to code reuse and abstraction. Option D is a tempting distractor because traits can have default implementations, but the primary benefit isn't the automatic provision of a default, but rather the ability to treat different types uniformly based on their shared behavior.

    Read the full bite: Rust Traits: Defining Shared Behavior

14. Question 14 of 30

    When you create b[1:4] from a Go slice b, how does the resulting value compare to borrowing &v[1..4] from a Rust Vec?

    • aBoth operations produce a three-word header containing pointer, length, and capacity, but Rust's borrow checker prevents mutation.
    • bThe Rust borrow stores capacity to prevent use-after-free when the Vec reallocates, while the Go slice omits capacity.
    • cThe Go operation allocates a new backing array for the sub-range, while the Rust borrow creates a two-word pointer into the existing buffer.
    • dThe Go result is a new three-word header sharing the original array, while the Rust result is a two-word borrowed slice with no capacity field.
    Show the answer

    Answer: d · The Go result is a new three-word header sharing the original array, while the Rust result is a two-word borrowed slice with no capacity field.

    Go slicing creates a new header (pointer, length, capacity) that points into the same underlying array, whereas Rust's &[T] is a two-word fat pointer without capacity because it is only a borrowed view. Distractor B is tempting because one might assume slicing copies data, but Go only copies the descriptor and shares the backing array.

    Read the full bite: Describe Go slice internals and compare to Rust slice and Vec

15. Question 15 of 30

    When auditing a request-rate counter that may overflow, which statement accurately distinguishes how Rust and Go handle fixed-width integer overflow by default in production release builds?

    • aGo silently wraps while Rust defaults to saturating arithmetic in release; Rust's wrapping_ methods panic in debug builds
    • bGo silently wraps while Rust always panics; Rust's saturating_ methods are the only way to avoid panics in debug
    • cBoth languages panic in debug but silently wrap in release; Rust provides checked_ methods to force panics
    • dRust panics on overflow only in debug builds and wraps in release like Go; Rust offers wrapping_ methods for explicit modular arithmetic
    Show the answer

    Answer: d · Rust panics on overflow only in debug builds and wraps in release like Go; Rust offers wrapping_ methods for explicit modular arithmetic

    Rust panics on integer overflow in debug builds but wraps silently in release builds, mirroring Go's default behavior, and the wrapping_ methods explicitly opt into modular arithmetic in any mode. Option B is tempting because many candidates mistakenly believe Rust always panics, but it actually wraps in release, and saturating_ clamps to bounds rather than preventing debug panics.

    Read the full bite: Default integer overflow behavior in Go versus Rust

16. Question 16 of 30

    When a Rust function attempts to parse user input that might be malformed, which error handling approach is most appropriate?

    • aReturning an Option<T> enum, where None signifies a parsing error.
    • bReturning a Result<T, E> enum, allowing the caller to handle the potential parsing failure gracefully.
    • cUsing panic! to immediately stop execution, as malformed input indicates a critical failure.
    • dIgnoring the malformed input and continuing with a default value, logging the issue internally.
    Show the answer

    Answer: b · Returning a Result<T, E> enum, allowing the caller to handle the potential parsing failure gracefully.

    The card specifies that Result<T, E> should be used for expected failures like parsing user input, which are conditions outside the program's direct control. panic! is reserved for unrecoverable programmer bugs, not anticipated external data issues.

    Read the full bite: Rust's Two Error Types: Recoverable vs. Unrecoverable

17. Question 17 of 30

    When designing a lookup function that may not find a value, what distinguishes Rust's Option<&T> from Go's *T at the type-system level?

    • aOption<&T> is just a nullable pointer with safer syntax, equivalent to Go's *T.
    • bRust's &T can be null like Go's *T, but pattern matching prevents dereferencing.
    • cOption<&T> explicitly encodes absence while &T remains non-null, costing no extra space via the null pointer optimization.
    • dOption<&T> always adds memory overhead because it stores an extra discriminant.
    Show the answer

    Answer: c · Option<&T> explicitly encodes absence while &T remains non-null, costing no extra space via the null pointer optimization.

    Option C is correct because Rust references are non-null by construction, and Option<&T> uses the null pointer optimization to represent None without extra memory, forcing compile-time handling of absence. Option A is a common misconception because Option is an algebraic data type with semantic guarantees that Go's implicit nullability lacks, not merely syntactic sugar.

    Read the full bite: Go nil pointers vs Rust Option: impact on signatures and safety

18. Question 18 of 30

    What characteristic most directly prevents an abstraction from being considered 'zero-cost'?

    • aIt significantly increases the final compiled binary size.
    • bIt necessitates runtime data or dynamic dispatch.
    • cIt involves many layers of nested function calls.
    • dIt leverages advanced generic programming features.
    Show the answer

    Answer: b · It necessitates runtime data or dynamic dispatch.

    An abstraction is not zero-cost if it requires runtime information, such as dynamic dispatch or allocations, because the compiler cannot prove it away entirely. While many function calls (option C) might seem costly, they can often be inlined and optimized away at compile time, which is a hallmark of zero-cost abstractions.

    Read the full bite: Zero-Cost Abstractions: Pay at Compile Time, Not Runtime

19. Question 19 of 30

    Regarding variable mutability, what is the fundamental difference between Rust and Go?

    • aRust variables are mutable by default, while Go variables are immutable by default, requiring a special keyword for change.
    • bBoth Rust and Go variables are mutable by default, but Rust provides a mechanism to declare them as immutable.
    • cBoth Rust and Go variables are immutable by default, but Go uses a simpler syntax for opting into mutability.
    • dRust variables are immutable by default and need an explicit keyword for mutability, whereas Go variables are mutable by default.
    Show the answer

    Answer: d · Rust variables are immutable by default and need an explicit keyword for mutability, whereas Go variables are mutable by default.

    The card explicitly states that Rust variables are immutable by default and require the 'mut' keyword to become mutable, while Go variables are mutable by default. Option A incorrectly swaps the default behaviors of the two languages.

    Read the full bite: Go vs. Rust: Variable Mutability by Default

20. Question 20 of 30

    Which statement correctly contrasts the scope of a Go if initializer's := binding with a Rust let binding inside a block?

    • aIn both Go and Rust, shadowing a variable mutates the original binding in place, allowing type changes in Go but not in Rust.
    • bIn Go, a variable declared with := in an if initializer is visible in both the if and else branches but not outside, while in Rust, a let binding inside a block is strictly confined to that block.
    • cIn Go, a variable declared with := in an if initializer is scoped only to the if branch body, while in Rust, a let binding inside a block leaks into sibling blocks.
    • dIn Go, := always mutates an existing outer variable of the same name instead of creating a new binding, while in Rust, shadowing with let requires the same type as the outer binding.
    Show the answer

    Answer: b · In Go, a variable declared with := in an if initializer is visible in both the if and else branches but not outside, while in Rust, a let binding inside a block is strictly confined to that block.

    The card states that Go's if initializer creates bindings visible in every branch of that if but not outside, whereas Rust's let inside a block is confined to that block. Option C reverses these scope rules, and option D repeats the common misconception that := always mutates rather than potentially shadowing.

    Read the full bite: Shadowing in Go and Rust: idioms, bugs, and if-block scoping

21. Question 21 of 30

    Given enum WebEvent { PageLoad, PageUnload, KeyPress(char) }, which line correctly instantiates the KeyPress variant with 'q'?

    • alet press = KeyPress('q');
    • blet press = WebEvent.KeyPress('q');
    • clet press = WebEvent::KeyPress { key: 'q' };
    • dlet press = WebEvent::KeyPress('q');
    Show the answer

    Answer: d · let press = WebEvent::KeyPress('q');

    Rust namespaces enum variants under the type with double colons, so WebEvent::KeyPress('q') is correct. WebEvent.KeyPress('q') is invalid because Rust does not use dot notation for enum variants, unlike some other languages.

    Read the full bite: Define a WebEvent enum with PageLoad, PageUnload, and KeyPress

22. Question 22 of 30

    What is the fundamental difference between variable shadowing and variable mutation in Rust?

    • aShadowing uses the let mut keyword to rebind a variable, while mutation uses let for simple value updates.
    • bShadowing is preferred for single-step transformations, while mutation is used for multiple, iterative value changes.
    • cShadowing allows a variable to change its type, whereas mutation only permits changes to its value without altering its type.
    • dShadowing declares a new variable that makes the previous one inaccessible, while mutation modifies the value of an existing variable in place.
    Show the answer

    Answer: d · Shadowing declares a new variable that makes the previous one inaccessible, while mutation modifies the value of an existing variable in place.

    Shadowing creates a completely new variable, potentially allocating new memory, making the original inaccessible. Mutation, however, changes the value of an existing variable in its current memory location. Option B describes when to use each, not the fundamental difference in their operation.

    Read the full bite: Rust's Variable Shadowing: Re-binding, Not Mutating

23. Question 23 of 30

    You want a Rust function to read a string without taking ownership and accept both a String variable and a literal. Which parameter type achieves this?

    • astr
    • b&str
    • c&String
    • dString
    Show the answer

    Answer: b · &str

    &str is a borrowed slice that coerces from &String and accepts literals directly, avoiding clones. &String is wrong because it rejects string literals, forcing callers to allocate a String they do not need.

    Read the full bite: What type replaces String for read-only function parameters in Rust?

24. Question 24 of 30

    What happens when you call .sum() directly on an iterator of Option<i32> that includes a None?

    • aIt panics when it encounters the first None
    • bIt treats every None as zero and returns the total sum
    • cIt returns None, short-circuiting the summation
    • dIt skips None values and returns the sum of the remaining Some values
    Show the answer

    Answer: c · It returns None, short-circuiting the summation

    The Sum<Option<U>> implementation returns None if any element is None, short-circuiting the entire operation. The other choices confuse this behavior with unwrap panics or assume automatic coercion of missing values.

    Read the full bite: Sum Some values in Vec<Option<i32>>, ignoring None

25. Question 25 of 30

    What is the primary purpose of using Rust's turbofish (`::<>`) or fully qualified syntax?

    • aTo explicitly define the type parameters for a new generic struct or enum.
    • bTo force the compiler to perform an unsafe type conversion between incompatible types.
    • cTo specify which trait's method to use when multiple traits define methods with the same name for a given type, or to provide type hints for generic functions.
    • dTo import specific items from a module or crate into the current scope.
    Show the answer

    Answer: c · To specify which trait's method to use when multiple traits define methods with the same name for a given type, or to provide type hints for generic functions.

    The card states the turbofish is used to resolve ambiguity when a type implements multiple traits with same-named methods, or to provide type hints for generic functions like `collect()`. Option C accurately describes these scenarios. Option A describes defining generics, not resolving ambiguity during their use.

    Read the full bite: Rust's Turbofish (`::<>`): When the Compiler Needs Help

26. Question 26 of 30

    On a 64-bit architecture, why can reordering struct fields from largest to smallest reduce memory usage in Go and Rust?

    • aThe compiler automatically reorders fields to optimize layout unless marked with a packed attribute.
    • bCompilers preserve source order and insert padding to satisfy alignment, which manual reordering minimizes.
    • cPadding is only added at the end of a struct to round its size to a multiple of eight bytes.
    • dSmaller fields inherit the alignment requirement of the preceding larger field.
    Show the answer

    Answer: b · Compilers preserve source order and insert padding to satisfy alignment, which manual reordering minimizes.

    The correct answer is C because Go and Rust maintain declared field order and insert padding bytes to meet alignment requirements; manually ordering fields by size reduces this internal padding. The most tempting distractor is A because candidates often incorrectly assume compilers automatically optimize struct layout, but the card explicitly states this is a red flag.

    Read the full bite: How does struct field ordering affect memory layout in Go and Rust?

27. Question 27 of 30

    What is the primary reason Box<T> is essential for defining recursive data structures in Rust?

    • aIt prevents stack overflow errors by allocating the entire structure on the heap.
    • bIt simplifies memory management by automatically deallocating nested elements.
    • cIt allows for dynamic dispatch over different elements within the recursive structure.
    • dIt ensures that the overall size of the recursive type can be determined at compile time.
    Show the answer

    Answer: d · It ensures that the overall size of the recursive type can be determined at compile time.

    The core problem Box<T> solves for recursive types is making their size known at compile time by storing the actual data on the heap and only keeping a fixed-size pointer on the stack. While Box<T> can help prevent stack overflows by moving data off the stack, this is a secondary effect; the primary issue for recursive types is their indeterminate size at compile time.

    Read the full bite: Using Box<T> for Heap Allocation in Rust

28. Question 28 of 30

    When choosing between an enum and boxed trait objects for a heterogeneous shape collection in Rust, which statement best captures a fundamental architectural difference?

    • aVec<Box<dyn Draw>> stores fat pointers and scatters shape data across heap allocations, while Vec<Shape> keeps all data contiguous with static dispatch.
    • bEnums permit downstream crates to add new shape variants without recompiling the collection code, while trait objects require exhaustive matching across the codebase.
    • cdyn Trait inherently requires Box and heap allocation, making trait objects unsuitable for stack-only environments.
    • dEnums cannot be iterated polymorphically and always waste more memory than boxed trait objects due to discriminant overhead.
    Show the answer

    Answer: a · Vec<Box<dyn Draw>> stores fat pointers and scatters shape data across heap allocations, while Vec<Shape> keeps all data contiguous with static dispatch.

    Vec<Shape> stores variants contiguously with static dispatch, while Vec<Box<dyn Draw>> uses fat pointers that scatter heap allocations and incur vtable indirection. The distractor claiming dyn Trait inherently requires Box is incorrect because trait objects only require indirection, which can also be provided by references.

    Read the full bite: Compare enum vs trait objects for heterogeneous shapes in Rust

29. Question 29 of 30

    How do Go and Rust respectively determine whether a function or type is accessible outside its immediate scope?

    • aGo uses capitalization to restrict visibility to the same source file, while Rust's pub keyword makes an item visible throughout the entire crate without restriction.
    • bBoth languages use Java-style access modifiers and enforce visibility rules at runtime through reflection.
    • cGo exports identifiers that start with an uppercase letter across packages, while Rust uses the pub keyword to make items visible outside their module.
    • dGo requires public and private keywords to control package visibility, while Rust items are public by default and must be marked private to hide them.
    Show the answer

    Answer: c · Go exports identifiers that start with an uppercase letter across packages, while Rust uses the pub keyword to make items visible outside their module.

    Go exports uppercase identifiers across packages, while Rust requires explicit pub for module-level visibility. Distractor B is tempting because it correctly names capitalization and pub but wrongly limits Go to file-level scope and Rust to unrestricted crate-wide visibility.

    Read the full bite: How do Go and Rust control visibility of functions and types?

30. Question 30 of 30

    What happens when a Rust Vec<T> is full and a new item is pushed into it?

    • aIt allocates a larger memory block, copies all existing items, then adds the new item.
    • bIt removes the first item to free up space for the new item at the end.
    • cIt creates a new, separate memory segment to store only the new item.
    • dIt reports an error indicating that its maximum capacity has been reached.
    Show the answer

    Answer: a · It allocates a larger memory block, copies all existing items, then adds the new item.

    When a Vec<T> is full, it reallocates by finding a new, larger contiguous memory block, copying all existing elements to it, and then adding the new element. This ensures the vector remains growable. Option D is incorrect because Vec<T> is designed to grow automatically, not to error out when capacity is reached.

    Read the full bite: Rust Vectors: Your Go-To Growable List