Top 30 Advanced Go & 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

   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

2. Question 2 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

3. Question 3 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

4. Question 4 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

5. Question 5 of 30

   In Go, if an outer struct defines a method M and embeds a type that also promotes M, what happens when M is called on the outer struct?

   • aThe outer struct's own method shadows the promoted method
   • bThe call is dispatched at runtime based on the concrete embedded type
   • cA compile-time ambiguity error occurs
   • dThe embedded method is invoked because embedding takes precedence
   Show the answer

   Answer: a · The outer struct's own method shadows the promoted method

   Go gives precedence to methods defined directly on the outer type, so the outer struct's method shadows the promoted one. Distractor B describes the compile-time ambiguity that occurs only when two embedded fields at the same depth promote identical method names, not when the outer type defines its own.

   Read the full bite: Explain Go struct embedding vs inheritance and method promotion

6. Question 6 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?

7. Question 7 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

8. Question 8 of 30

   In a large Rust plugin system, why does a workspace of plugin crates typically give better incremental build times than one crate with module plugins?

   • aThe crate is the compilation unit, so separate crates rebuild independently while a module change rebuilds the whole crate
   • bModules force a full recompile because Rust cannot parse them incrementally
   • cWorkspaces compile all crates in parallel on a single core
   • dModules are never cached, but workspaces disable caching entirely
   Show the answer

   Answer: a · The crate is the compilation unit, so separate crates rebuild independently while a module change rebuilds the whole crate

   Because the crate is Rust's compilation unit, changing one plugin crate recompiles only it and its dependents, whereas a module lives inside one crate that rebuilds wholesale on any change. Caching applies to crates, not the reverse of the first option.

   Read the full bite: Rust workspace versus single crate for plugins

9. Question 9 of 30

   Which statement accurately contrasts Go's escape analysis with Rust's ownership regarding garbage collection and memory placement?

   • aRust's ownership system reduces tracing GC pause times but still relies on a runtime garbage collector for heap-allocated values.
   • bGo's escape analysis eliminates the garbage collector by ensuring all function-local data remains on the stack.
   • cGo uses escape analysis within a garbage-collected runtime to keep non-escaping locals on the stack, while Rust's ownership enforces deterministic lifetimes that remove the need for a tracing garbage collector entirely.
   • dBoth languages use compile-time proofs to guarantee that values with fixed sizes are always stack-allocated unless the programmer explicitly requests heap allocation.
   Show the answer

   Answer: c · Go uses escape analysis within a garbage-collected runtime to keep non-escaping locals on the stack, while Rust's ownership enforces deterministic lifetimes that remove the need for a tracing garbage collector entirely.

   Go's escape analysis is a compile-time optimization that reduces heap size and GC workload, but it does not eliminate the garbage collector. Option B is wrong because Go still requires a GC for values that escape to the heap, whereas Rust's ownership system avoids tracing GC costs entirely by enforcing deterministic lifetimes at compile time.

   Read the full bite: Explain Go escape analysis and Rust ownership for stack vs heap

10. Question 10 of 30

    Which statement correctly contrasts memory reclamation for reference cycles in Rust Rc versus Go's tracing GC?

    • aRust's borrow checker prevents reference cycles at compile time for Rc, while Go's GC must pause the world to sweep unreachable cycles.
    • bBoth Rc and Go's GC provide immediate, deterministic reclamation when the last external reference is dropped, differing only in thread-safety overhead.
    • cRc leaks cyclic object graphs because internal counts never reach zero, whereas Go's tracing GC can identify and reclaim unreachable cycles.
    • dGo's root-tracing GC leaks cyclic graphs because it cannot distinguish internal pointers from external ones, while Rc handles cycles via drop decrements.
    Show the answer

    Answer: c · Rc leaks cyclic object graphs because internal counts never reach zero, whereas Go's tracing GC can identify and reclaim unreachable cycles.

    Rc only deallocates when its reference count reaches zero, so a cycle of Rc pointers keeps counts above zero and leaks memory, while Go's tracing GC starts from roots and can mark an unreachable cycle for collection. Option A is tempting but wrong because the borrow checker does not prevent Rc reference cycles at compile time.

    Read the full bite: Explain Rust Rc and Arc versus Go's tracing GC

11. Question 11 of 30

    Which statement accurately contrasts Rust unsafe FFI and Cgo when passing a buffer to a C compression library?

    • aRust unsafe blocks suspend all compiler checks, allowing arbitrary pointer operations like C, whereas Cgo copies Go data to C memory and restricts pointer storage to protect the GC.
    • bIn Rust, the programmer must manually guarantee pointer validity and lifetimes across the boundary, while Cgo automatically copies slices and forbids storing Go pointers in C memory.
    • cBoth Rust and Go treat the FFI boundary as a runtime trust boundary where the toolchain inserts checks and copies to prevent GC and aliasing issues.
    • dCgo passes Go pointers directly to C without runtime copying, while Rust unsafe requires the programmer to copy all buffers to the C heap before calling extern functions.
    Show the answer

    Answer: b · In Rust, the programmer must manually guarantee pointer validity and lifetimes across the boundary, while Cgo automatically copies slices and forbids storing Go pointers in C memory.

    Rust unsafe shifts the proof burden to the programmer, who must ensure pointer validity and aliasing rules for zero-cost FFI, while Cgo trades performance for safety by automatically copying data and restricting Go pointers in C memory. Option A is a common misconception: unsafe does not disable all compiler checks or Rust's underlying aliasing invariants.

    Read the full bite: Rust unsafe FFI vs Cgo: who owns memory safety?

12. Question 12 of 30

    When defining a custom struct-based error type that wraps an underlying error to add context, which implementation choice is required for errors.Is and errors.As to traverse the wrapper?

    • aOmit Unwrap because the Error method already exposes the underlying text
    • bBuild the error message with fmt.Errorf using %v to include the cause text
    • cStore the underlying error in an exported field named Cause
    • dImplement an Unwrap method returning the underlying error field
    Show the answer

    Answer: d · Implement an Unwrap method returning the underlying error field

    errors.Is and errors.As rely on the Unwrap method to walk the chain; without it, they cannot reach the underlying sentinel even if Error surfaces its text. Simply exposing a field or stringifying with %v does not provide the unwrapping contract.

    Read the full bite: Design a custom Go error type with context, Is, As, and Unwrap

13. Question 13 of 30

    When is reaching for panic (or unwrap) appropriate in idiomatic Go and Rust?

    • aWhenever validating user input to avoid writing error handling
    • bFor unrecoverable bugs or violated invariants, while expected failures use error or Result values
    • cOnly in Rust; Go should never use panic under any circumstance
    • dFor any expected failure, since it is faster than returning a value
    Show the answer

    Answer: b · For unrecoverable bugs or violated invariants, while expected failures use error or Result values

    Both languages reserve panic for unrecoverable programmer errors and broken invariants, returning error or Result for expected failures. Using panic for routine validation or expected input errors is an anti-pattern in both.

    Read the full bite: When to panic in Go versus Rust

14. Question 14 of 30

    In Rust's crate ecosystem, what is the primary risk that the orphan rule prevents when multiple unrelated crates depend on common standard library types and traits?

    • aUnauthorized access to private fields of foreign types by associating them with new trait implementations.
    • bName collisions between trait methods when crates export similar APIs, forcing manual disambiguation at every call site.
    • cTwo unrelated crates defining the same foreign trait implementation for a foreign type, causing unresolvable conflicts in downstream crates that depend on both.
    • dMultiple valid trait implementations overlapping for the same type within a single crate, making method dispatch ambiguous.
    Show the answer

    Answer: c · Two unrelated crates defining the same foreign trait implementation for a foreign type, causing unresolvable conflicts in downstream crates that depend on both.

    The orphan rule maintains global coherence by ensuring only the crate owning a trait or type can add implementations, preventing unresolvable conflicts when unrelated crates add the same foreign impl. The overlap rule governs ambiguous impls within a single crate, which is a distinct concern from cross-crate orphan violations.

    Read the full bite: Describe Rust's orphan rule and its ecosystem purpose

15. Question 15 of 30

    Why does the standard library make Item an associated type on Iterator rather than a generic parameter Iterator<Item>?

    • aBecause generic trait parameters are not allowed in the standard library
    • bBecause associated types permit a type to implement Iterator many times
    • cBecause associated types compile faster than generic parameters
    • dBecause a type yields exactly one element type, so associated types keep next() inference unambiguous
    Show the answer

    Answer: d · Because a type yields exactly one element type, so associated types keep next() inference unambiguous

    Each iterator produces one element type, so an associated type uniquely determines Item and next() infers without annotation. The last option is backwards: generics, not associated types, would allow multiple impls.

    Read the full bite: Associated types vs generic type parameters in traits

16. Question 16 of 30

    Why might a program using Relaxed atomics for cross-thread flags pass tests on x86 yet fail on ARM?

    • aThe Rust compiler emits stronger instructions for Relaxed atomics on x86 than on ARM, so the same source code compiles to different semantics.
    • bx86's strongly-ordered hardware prevents the reorderings that Relaxed permits, masking visibility bugs that appear on ARM's weakly-ordered hardware.
    • cx86 guarantees cache coherence across all cores automatically, while ARM requires SeqCst to synchronize caches and make writes visible.
    • dx86 automatically upgrades Relaxed operations to Acquire-Release semantics, whereas ARM requires explicit fence instructions for the same behavior.
    Show the answer

    Answer: b · x86's strongly-ordered hardware prevents the reorderings that Relaxed permits, masking visibility bugs that appear on ARM's weakly-ordered hardware.

    Correct because the card states x86's strong hardware ordering suppresses reorderings that Relaxed allows, hiding visibility bugs that ARM's weak ordering exposes. Distractor A is tempting but wrong because x86 does not formally upgrade Relaxed to Acquire-Release semantics; relying on its hardware behavior is an unsupported portability trap.

    Read the full bite: When should Rust atomics replace a Mutex, and how do orderings work?

17. Question 17 of 30

    In a Rust workspace with a server, core library, and client crate, what specific problem does the single shared Cargo.lock primarily prevent?

    • aDifferent workspace members resolving incompatible versions of the same transitive dependency, causing type mismatches across crate boundaries.
    • bBuild artifacts being duplicated across separate target directories, increasing disk usage and compile times.
    • cWorkspace inheritance failing to propagate shared metadata to downstream consumers on crates.io.
    • dVirtual manifests being unable to infer the dependency resolver edition from a root package section.
    Show the answer

    Answer: a · Different workspace members resolving incompatible versions of the same transitive dependency, causing type mismatches across crate boundaries.

    The card's concrete example states that without a shared Cargo.lock, member crates can pull in different versions of a transitive dependency like tokio, causing type mismatches when structures cross crate boundaries. The shared target directory reduces disk usage, but that is a separate feature from the lockfile's role in unifying dependency resolution.

    Read the full bite: How do you manage multiple related Rust crates as a single unit?

18. Question 18 of 30

    How does a build.rs script tell the Rust compiler to link against a native library it just compiled?

    • aBy modifying Cargo.toml at runtime to add the library
    • bBy placing the library in the target/ directory where rustc auto-discovers it
    • cBy calling rustc directly with command-line link flags
    • dBy printing cargo:rustc-link-lib and cargo:rustc-link-search directives to stdout
    Show the answer

    Answer: d · By printing cargo:rustc-link-lib and cargo:rustc-link-search directives to stdout

    Cargo reads the script's stdout and acts on cargo: directives like rustc-link-lib and rustc-link-search. The script does not edit Cargo.toml or invoke rustc itself, and rustc does not auto-discover libraries by directory.

    Read the full bite: Purpose and mechanism of a Rust build.rs script

19. Question 19 of 30

    You manually add a require directive to go.mod and skip go mod tidy. Your build passes locally, but a teammate with a fresh module cache sees a security error. What explains this discrepancy?

    • aTidy downloads all module source code into the vendor directory. Skipping it means the teammate's build cannot find the packages because they are not vendored.
    • bTidy upgrades all dependencies to their latest compatible versions, which updates go.sum. Skipping it leaves outdated checksums that no longer match the proxy's current versions.
    • cTidy computes the minimal build list via MVS and ensures go.sum contains checksums for every module in that list, including indirect dependencies. Without it, missing checksums cause verification failures on fresh caches.
    • dTidy resolves imports only for non-test packages. Skipping it causes test dependencies to be omitted from go.mod, triggering a security error when those tests run on the teammate's machine.
    Show the answer

    Answer: c · Tidy computes the minimal build list via MVS and ensures go.sum contains checksums for every module in that list, including indirect dependencies. Without it, missing checksums cause verification failures on fresh caches.

    go mod tidy computes the minimal build list using Minimal Version Selection and populates go.sum with checksums for every module, which fresh caches need for verification. Distractor A is tempting but incorrect because tidy does not upgrade dependencies to their latest versions; it only resolves the minimal versions actually imported by the code.

    Read the full bite: What does go mod tidy do beyond adding dependencies?

20. Question 20 of 30

    How do Go and Rust standard libraries differ in expressing a socket read timeout?

    • aGo's SetReadDeadline takes an absolute time.Time while Rust's set_read_timeout takes a relative Option<Duration>
    • bNeither standard library supports per-operation socket timeouts
    • cBoth take a relative duration argument with identical semantics
    • dRust uses absolute deadlines and Go uses relative durations
    Show the answer

    Answer: a · Go's SetReadDeadline takes an absolute time.Time while Rust's set_read_timeout takes a relative Option<Duration>

    Go expresses deadlines as absolute time.Time values that compose with request budgets, whereas Rust's std takes a relative Duration per socket. The roles are not reversed and both clearly support timeouts.

    Read the full bite: Network read/write timeouts in Go vs Rust stdlib

21. Question 21 of 30

    Why must a Rust synchronous server pair its custom cancellation flag with a socket read timeout to support graceful shutdown?

    • aBecause setting the flag cannot interrupt a thread already blocked on a socket read, so a timeout lets the loop wake and re-check
    • bBecause AtomicBool is not thread-safe without a timeout
    • cBecause read timeouts automatically cancel all running threads
    • dBecause Rust std provides context.Context only when a timeout is set
    Show the answer

    Answer: a · Because setting the flag cannot interrupt a thread already blocked on a socket read, so a timeout lets the loop wake and re-check

    Cancellation is cooperative; a blocked read ignores the flag, so a read timeout returns control to the loop to observe the flag. Rust std has no context.Context, and timeouts affect only the one socket operation.

    Read the full bite: Cancellation: Go context vs Rust sync stdlib

22. Question 22 of 30

    When hunting a memory leak in a Go service, why is inuse_space more useful than alloc_space?

    • aalloc_space is only available in test builds, not production
    • binuse_space shows memory still retained after GC, so its steady growth signals a leak; alloc_space counts cumulative allocation including freed memory
    • cinuse_space and alloc_space are identical for any long-running service
    • dalloc_space measures live retention while inuse_space measures allocation rate
    Show the answer

    Answer: b · inuse_space shows memory still retained after GC, so its steady growth signals a leak; alloc_space counts cumulative allocation including freed memory

    inuse_space reflects currently retained memory, so rising inuse across snapshots indicates a leak; alloc_space is cumulative allocation that stays high even when memory is freed. The roles are not swapped and the metrics are not identical.

    Read the full bite: Diagnosing Go memory leaks with pprof heap profiles

23. Question 23 of 30

    Before using perf annotate to map cache-miss counters to Rust source, what build configuration is essential?

    • aA build with all optimizations disabled and LTO on
    • bA debug build so the optimizer does not change the code
    • cA release build with debug symbols enabled so perf can map addresses to source lines
    • dAny build, since perf reads source files directly without symbols
    Show the answer

    Answer: c · A release build with debug symbols enabled so perf can map addresses to source lines

    You profile optimized release code but must keep debug symbols so perf maps sampled addresses back to functions and lines. A debug build distorts hotspots, and perf needs symbol info, not raw source access.

    Read the full bite: Profiling a Rust hot loop with perf

24. Question 24 of 30

    Which best explains why Go's standard library provides built-in HTTP profiling endpoints while Rust's does not?

    • aGo's approach adds significant memory and CPU overhead to every program, while Rust's zero-cost philosophy prohibits any built-in observability mechanisms.
    • bRust programs are typically compiled without symbol tables, making runtime profiling impossible without recompiling with external crates.
    • cGo's runtime already maintains profiling state, so exposing it via HTTP is a low-cost side effect, whereas Rust avoids runtime overhead and leaves profiling to external tools or explicit dependencies.
    • dRust's standard library is too immature to include profiling endpoints, whereas Go's longer history allowed it to integrate pprof into the runtime.
    Show the answer

    Answer: c · Go's runtime already maintains profiling state, so exposing it via HTTP is a low-cost side effect, whereas Rust avoids runtime overhead and leaves profiling to external tools or explicit dependencies.

    Go's bundled runtime already maintains profiling counters for its scheduler and garbage collector, so exposing them via HTTP is nearly free, whereas Rust's zero-cost design pushes observability to explicit crates or OS-level tools. Option A is tempting but wrong because it claims Go's approach adds significant overhead, when in fact the runtime already incurs that cost and the HTTP layer is a minor side effect.

    Read the full bite: Compare Go and Rust approaches to exposing profiling data

25. Question 25 of 30

    In a proc-macro derive that generates a Builder pattern, what is the primary role of the quote crate in the final step?

    • aTo convert a Rust-like template into a TokenStream while preserving hygiene for generated identifiers
    • bTo validate that the generated builder code compiles before returning it to the compiler
    • cTo provide procedural hooks that allow the macro to modify the original struct definition in place
    • dTo parse the input TokenStream into a typed AST representing the target struct
    Show the answer

    Answer: a · To convert a Rust-like template into a TokenStream while preserving hygiene for generated identifiers

    The card explains that quote turns Rust-like syntax back into a TokenStream and preserves hygiene so generated identifiers do not collide with user code. Option D describes syn's role, and D reflects the common misconception that derive macros can modify the original struct.

    Read the full bite: Implement a custom derive macro for a Builder pattern

26. Question 26 of 30

    What is the central risk when using unsafe to alias a Go string's bytes as a []byte without copying?

    • aThe slice loses its length information and becomes unusable
    • bIt forces a garbage collection on every access
    • cWriting through the resulting slice mutates an immutable string, which is undefined behavior
    • dThe conversion still allocates, defeating the purpose
    Show the answer

    Answer: c · Writing through the resulting slice mutates an immutable string, which is undefined behavior

    Strings are immutable and may reside in read-only memory, so writing through an aliased slice is undefined behavior that can corrupt shared strings. The whole point of the technique is to avoid the allocation, so it does not copy.

    Read the full bite: Zero-copy string to []byte conversion via unsafe in Go

27. Question 27 of 30

    Why must a safe Rust wrapper use a local size_t variable rather than a pointer to the Vec's length field when calling a C buffer-output function?

    • aThe Vec length field is private and safe Rust cannot form a pointer to it.
    • bA local variable is required to validate the output count against capacity before calling set_len.
    • cLetting C write directly into the Vec's metadata violates Rust invariants and causes undefined behavior.
    • dVec uses usize for length while C expects size_t, so an intermediate variable is needed for type compatibility.
    Show the answer

    Answer: c · Letting C write directly into the Vec's metadata violates Rust invariants and causes undefined behavior.

    The correct answer is C because Vec's length is internal metadata managed by Rust; allowing C to modify it directly breaks invariants and is undefined behavior even if the value written is correct. Option B describes a necessary validation step but does not explain why the local variable must be used instead of the Vec's length field—if C wrote directly to the field, the Vec would already be corrupted before validation could occur.

    Read the full bite: Design a safe Rust wrapper taking &[i32] and returning Vec<i32>

28. Question 28 of 30

    In a safe Rust wrapper over a C API, what is the idiomatic way to guarantee a C-owned resource is released exactly once?

    • aExpose a public free() method and document that callers must call it
    • bRely on the Rust garbage collector to reclaim the handle
    • cCall the destructor in the constructor after acquiring the resource
    • dImplement Drop on the owning struct so the C destructor runs automatically when the value goes out of scope
    Show the answer

    Answer: d · Implement Drop on the owning struct so the C destructor runs automatically when the value goes out of scope

    Implementing Drop gives RAII, releasing the resource deterministically once, even on panic, without caller action. A manual free invites leaks and double frees, and Rust has no garbage collector.

    Read the full bite: Building a safe Rust wrapper over an unsafe C API

29. Question 29 of 30

    In a cgo preamble, what is the difference between #cgo CFLAGS and #cgo LDFLAGS?

    • aCFLAGS runs pkg-config while LDFLAGS disables it
    • bBoth are passed only to the linker at the final stage
    • cCFLAGS is passed to the C compiler for include paths and defines; LDFLAGS is passed to the linker for library paths and libraries
    • dCFLAGS sets linker library paths; LDFLAGS sets compiler include paths
    Show the answer

    Answer: c · CFLAGS is passed to the C compiler for include paths and defines; LDFLAGS is passed to the linker for library paths and libraries

    CFLAGS configures the compile step (-I, -D) so the C compiles, and LDFLAGS configures the link step (-L, -l) so symbols resolve. The first option reverses these roles, and pkg-config is a separate directive emitting both.

    Read the full bite: cgo directives: CFLAGS, LDFLAGS, and pkg-config

30. Question 30 of 30

    For an L7 proxy with a strict p99 latency SLA under heavy connection churn, which Go characteristic is the primary architectural concern?

    • aGarbage collection pauses can spike tail latency
    • bGo cannot perform TLS termination
    • cGoroutines are too expensive to create at scale
    • dGo lacks any way to handle concurrent connections
    Show the answer

    Answer: a · Garbage collection pauses can spike tail latency

    Go's GC introduces pauses and allocation pressure that surface as p99/p999 spikes, which is the chief tail-latency risk. Goroutines are cheap, Go handles concurrency well, and TLS termination is fully supported.

    Read the full bite: Architecting an L7 proxy in Go versus Rust