Top 30 Intermediate 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

   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

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

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

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

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

6. Question 6 of 30

   Which solution best supports many concurrent readers on a typed Go map while keeping compile-time type safety?

   • aStore the map in a struct guarded by sync.Mutex with Lock for both reads and writes
   • bUse sync.Map directly with typed keys and values
   • cAccess a plain map concurrently after setting runtime.GOMAXPROCS to 1
   • dWrap the map in a struct with sync.RWMutex, using RLock for reads and Lock for writes
   Show the answer

   Answer: d · Wrap the map in a struct with sync.RWMutex, using RLock for reads and Lock for writes

   An RWMutex-wrapped map allows multiple simultaneous readers and retains compile-time type safety. sync.Map is tempting because it handles concurrency internally, but it stores interface{} values and therefore sacrifices compile-time type checking.

   Read the full bite: How do you safely share a Go map across goroutines?

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

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

9. Question 9 of 30

   An abstract domain package and a concrete storage package import each other. Which refactor best restores clean architecture?

   • aMove all domain logic into the storage package to eliminate the upward import
   • bMerge both packages into a single package since they are already tightly coupled
   • cUse build tags to hide the cyclic imports from the compiler
   • dDefine a storage interface in the domain layer and inject the concrete implementation at startup
   Show the answer

   Answer: d · Define a storage interface in the domain layer and inject the concrete implementation at startup

   Defining the interface in the domain layer and injecting the concrete implementation at startup inverts the dependency, which is the recommended pattern for layer violations. Merging is better reserved for packages with no clear hierarchy, and build tags are a red-flag workaround that avoids fixing the design.

   Read the full bite: Why does Go forbid circular dependencies, and how do you resolve them?

10. Question 10 of 30

    Why is putting core logic in lib.rs and keeping main.rs thin the idiomatic structure for a tool that is both a CLI and a reusable library?

    • aA package may contain only one crate, so logic must go in lib.rs
    • bLogic in lib.rs is importable by other crates and unit-testable, while main.rs just wires it to the CLI
    • cmain.rs cannot contain any functions other than main
    • dCargo refuses to compile a package with both main.rs and lib.rs
    Show the answer

    Answer: b · Logic in lib.rs is importable by other crates and unit-testable, while main.rs just wires it to the CLI

    Code in lib.rs forms a public, importable, testable API, so other crates and integration tests can use it; main.rs becomes a thin adapter. A package can hold both a binary and a library, contrary to the other options.

    Read the full bite: Rust binary and library crates in one project

11. Question 11 of 30

    You move a helper package into an internal directory to restrict its use to your module. Which statement about the effects is true?

    • aExternal modules are blocked from importing it by the compiler, while sibling packages in the same module can still import it freely
    • bIt provides the same module-level privacy as using lowercase unexported identifiers in the helper package
    • cIt hides the package from all other packages, including those within the same module
    • dIt is a naming convention without compiler enforcement, relying only on team discipline
    Show the answer

    Answer: a · External modules are blocked from importing it by the compiler, while sibling packages in the same module can still import it freely

    The Go compiler rejects imports of internal packages from outside the module, yet packages inside the same module may import them normally. Option B is tempting because unexported identifiers also limit visibility, but they only restrict access within a single package, not across packages in a module.

    Read the full bite: What is the purpose of the internal directory in Go?

12. Question 12 of 30

    When building a multi-file Rust crate, what is the key difference between mod and use?

    • ause is mandatory for accessing public items in another module, while mod determines whether the declared submodule is public or private.
    • bBoth mod and use insert new modules into the crate tree, but mod declares submodules while use re-exports them.
    • cmod declares external dependencies listed in Cargo.toml, while use brings those dependencies into the current scope.
    • dmod adds a module to the crate tree and tells the compiler where to find its source, whereas use merely creates a local shortcut to a path already in the tree.
    Show the answer

    Answer: d · mod adds a module to the crate tree and tells the compiler where to find its source, whereas use merely creates a local shortcut to a path already in the tree.

    mod tells the compiler to include a new module in the crate tree and locate its source file, while use only creates a local shortcut to an item already in that tree. Distractor A is wrong because use never inserts modules into the crate tree or declares anything new; calling both keywords imports is a common misconception.

    Read the full bite: Explain the difference between mod and use in Rust

13. Question 13 of 30

    What is the key difference in how Rust and Go prevent data races on shared mutable state?

    • aRust makes them a compile error via aliasing-XOR-mutability and Send/Sync; Go relies on runtime discipline and the race detector
    • bBoth prevent data races at compile time using identical borrow rules
    • cGo prevents them at compile time while Rust only catches them at runtime
    • dNeither language offers any way to detect data races
    Show the answer

    Answer: a · Rust makes them a compile error via aliasing-XOR-mutability and Send/Sync; Go relies on runtime discipline and the race detector

    Rust's borrow checker plus Send and Sync turn data races into compile errors, while Go has no compile-time guarantee and instead uses channels, mutexes, and the runtime race detector. The languages do not share identical rules.

    Read the full bite: Rust borrow rules versus Go race prevention

14. Question 14 of 30

    Why can Rust reclaim heap memory at a specific moment without the latency spikes typical of Go's GC?

    • aRust uses a reference-counting scheme for heap objects, spreading memory management cost across pointer operations.
    • bRust enforces ownership at compile time, so Drop deallocates heap memory deterministically when values go out of scope.
    • cRust's runtime schedules background sweeper threads that reclaim memory during idle CPU cycles without stopping the world.
    • dRust performs all heap allocation on the stack through compile-time size analysis, eliminating dynamic memory entirely.
    Show the answer

    Answer: b · Rust enforces ownership at compile time, so Drop deallocates heap memory deterministically when values go out of scope.

    Rust's compiler tracks ownership and lifetimes, guaranteeing that heap memory is freed immediately when a value goes out of scope via Drop, eliminating non-deterministic pauses. Distractor D confuses Rust's default compile-time ownership with opt-in reference counting types like Rc and Arc, which do incur runtime overhead but are not the standard mechanism.

    Read the full bite: How does Rust ownership avoid Go GC's non-deterministic pauses?

15. Question 15 of 30

    An error wrapped with fmt.Errorf using %w contains an underlying *os.PathError. Which approach lets you safely extract its Path field?

    • aDirectly assert the error to *os.PathError using a type assertion
    • bManually call Unwrap in a loop until you find the underlying type
    • cUse errors.Is to compare against an os.PathError value
    • dUse errors.As with a pointer to a *os.PathError variable
    Show the answer

    Answer: d · Use errors.As with a pointer to a *os.PathError variable

    errors.As traverses the unwrap chain and copies a matching *os.PathError into the target pointer so you can read its Path field. A direct type assertion only inspects the top-level error and silently fails when wrapping is present.

    Read the full bite: Difference between errors.Is and errors.As in Go

16. Question 16 of 30

    When is it appropriate to use unwrap or expect in production Rust code?

    • aOnly in tests and prototypes, because panicking is never justified in released binaries
    • bWhen an invariant is statically guaranteed, such as parsing a compile-time embedded asset that must exist
    • cWhen handling expected runtime failures like missing files or network timeouts, to avoid verbose error propagation
    • dWhen you need to emit a developer-facing warning but continue executing the current function
    Show the answer

    Answer: b · When an invariant is statically guaranteed, such as parsing a compile-time embedded asset that must exist

    unwrap and expect are intended for unrecoverable invariant violations, not routine errors, and the card explicitly cites statically guaranteed cases like compile-time assets as legitimate production uses. Distractor B is tempting because many developers believe panicking is never acceptable in production, but the card identifies this as dogmatic overcorrection that ignores justified scenarios like poisoned mutexes or bundled static assets.

    Read the full bite: What is the difference between unwrap and expect on Option and Result?

17. Question 17 of 30

    What must you implement to let the ? operator automatically convert std::io::Error into a custom enum error type?

    • aWrapping each call with map_err before applying ?
    • bImplementing From<std::io::Error> for the custom enum
    • cRequiring every function in the call graph to return the same error type
    • dImplementing TryFrom<std::io::Error> for the custom enum
    Show the answer

    Answer: b · Implementing From<std::io::Error> for the custom enum

    The ? operator desugars to a match that returns Err(From::from(err)) on failure, so implementing From<std::io::Error> for the custom enum is what enables automatic conversion. Manually using map_err on every call site is a common misconception that creates unnecessary boilerplate instead of leveraging the type system.

    Read the full bite: How does the question mark operator use From to unify error types?

18. Question 18 of 30

    When a nil pointer is boxed into an interface{}, why does a subsequent nil check on that interface return false?

    • aBare type assertions on such interfaces always panic at runtime
    • bThe interface value carries type information, so it is not nil
    • cThe any alias stores nil pointers using a different internal representation
    • dThe boxed pointer must be unwrapped with a type assertion before nil can be detected
    Show the answer

    Answer: b · The interface value carries type information, so it is not nil

    An interface{} holding a nil pointer is non-nil because it stores dynamic type metadata alongside the data pointer. Distractor D is wrong because a bare type assertion panics only when the dynamic type does not match, not when the underlying concrete value is nil.

    Read the full bite: Explain Go's empty interface, safe usage, and runtime risks

19. Question 19 of 30

    When using impl Trait in argument position rather than Box<dyn Trait>, what trade-off does Rust make?

    • aIt hides the concrete type from the caller to reduce compile-time crate dependencies.
    • bIt removes object safety restrictions so traits with generic methods can use dynamic dispatch.
    • cIt generates a specialized function copy per concrete type, speeding up execution but bloating the binary.
    • dIt stores heterogeneous writers in a vector and dispatches through a vtable at runtime.
    Show the answer

    Answer: c · It generates a specialized function copy per concrete type, speeding up execution but bloating the binary.

    impl Trait in argument position desugars to a generic parameter, triggering monomorphization that creates a specialized function per concrete type for zero-cost abstraction at the expense of binary size. Option D describes Box<dyn Trait>, which relies on a fat pointer and vtable lookup for runtime polymorphism instead of compile-time code duplication.

    Read the full bite: Static dispatch with impl Trait versus dynamic dispatch with Box<dyn Trait>

20. Question 20 of 30

    A Go type has a method with a pointer receiver that an interface requires. Why does a plain value of that type fail to satisfy the interface?

    • aGo copies the value, which strips all its methods
    • bThe interface must also declare a pointer receiver
    • cValue types cannot implement any interfaces in Go
    • dPointer-receiver methods are in the method set of *T only, not T, so only a pointer satisfies the interface
    Show the answer

    Answer: d · Pointer-receiver methods are in the method set of *T only, not T, so only a pointer satisfies the interface

    The method set of T contains only value-receiver methods, while *T's set adds the pointer-receiver ones, so only a pointer satisfies an interface needing that method. Interfaces do not declare receivers, and values can satisfy interfaces when methods use value receivers.

    Read the full bite: Value versus pointer receivers and interface satisfaction

21. Question 21 of 30

    What is the key safety difference between Go's sync.Mutex idiom and Rust's Arc<Mutex<T>> when sharing mutable state across threads?

    • aBoth prevent data races at compile time with equivalent guarantees
    • bRust's Mutex avoids any runtime locking overhead
    • cRust makes locking structurally mandatory and rejects races at compile time, while Go relies on convention plus an optional runtime detector
    • dGo is faster because it avoids reference counting entirely
    Show the answer

    Answer: c · Rust makes locking structurally mandatory and rejects races at compile time, while Go relies on convention plus an optional runtime detector

    Rust hides the data behind the lock guard and enforces Send/Sync at compile time, whereas Go's lock-data pairing is a convention checked only at runtime via the race detector. The 'equivalent' and 'no overhead' claims are false.

    Read the full bite: Sharing mutable state: Go mutex vs Rust Arc Mutex

22. Question 22 of 30

    In Rust, what happens to an async function's returned future immediately after you call the function but before awaiting or spawning it?

    • aIt is scheduled automatically by the built-in Rust runtime
    • bIt runs to completion on a background OS thread
    • cNothing executes; the future is inert until a runtime polls it
    • dIt blocks the calling thread until the work finishes
    Show the answer

    Answer: c · Nothing executes; the future is inert until a runtime polls it

    Rust futures are lazy state machines that do nothing until polled by an executor like Tokio. Go's eager goroutine scheduling, not Rust's, runs work automatically when launched.

    Read the full bite: Rust async/await vs Go goroutines

23. Question 23 of 30

    Which pattern correctly uses context.WithCancel to manage a worker goroutine?

    • aStore the context in a struct and have the worker check a shared shutdown flag
    • bDerive a child context, pass it to the worker, and call cancel from the caller to unblock ctx.Done
    • cPass the CancelFunc to the worker so it can call cancel to stop itself
    • dRely on ctx.Done closing automatically without ever calling the CancelFunc
    Show the answer

    Answer: b · Derive a child context, pass it to the worker, and call cancel from the caller to unblock ctx.Done

    The caller derives the child context, passes it to the worker, and later calls cancel to close ctx.Done so the worker exits cleanly. Option D is tempting because Done appears to signal cancellation automatically, but ignoring the CancelFunc leaks the child context until the parent is canceled.

    Read the full bite: What is Go's context package and how do you use WithCancel?

24. Question 24 of 30

    Which statement accurately contrasts Go's select and Tokio's select! when multiple branches are ready in a loop?

    • aTokio polls branches in strict source order by default to minimize overhead, while Go only randomizes when channels have equal priority.
    • bTokio's randomized default is an unintentional performance bug, whereas Go's randomization is an intentional starvation-avoidance mechanism.
    • cGo evaluates cases in source order to honor declaration priority, while Tokio defaults to randomized polling but allows deterministic ordering via the biased; annotation.
    • dGo pseudo-randomly selects among ready cases to prevent starvation, while Tokio defaults to randomized polling but offers biased; for strict top-down evaluation with starvation risk.
    Show the answer

    Answer: d · Go pseudo-randomly selects among ready cases to prevent starvation, while Tokio defaults to randomized polling but offers biased; for strict top-down evaluation with starvation risk.

    Go's select mandatorily pseudo-randomizes among ready cases, making source order irrelevant, whereas Tokio's select! randomizes by default for fairness but accepts the biased; annotation for deterministic top-down polling, though this can starve later branches if earlier ones are always ready. Option C is tempting because it correctly describes Tokio's biased; mode but incorrectly claims Go uses source order.

    Read the full bite: Go select vs Rust select! fairness and determinism

25. Question 25 of 30

    What is the correct way to detect an unsynchronized concurrent memory access in a Go package during development?

    • aRun go vet to statically detect unsynchronized memory accesses across goroutines
    • bDeploy the application with go build -race enabled for continuous production monitoring
    • cDownload the race detector separately and run it as an external sanitizer on the compiled binary
    • dCompile and run tests with go test -race to dynamically detect concurrent unsynchronized accesses
    Show the answer

    Answer: d · Compile and run tests with go test -race to dynamically detect concurrent unsynchronized accesses

    The -race flag is built into the go command and instruments binaries at compile time to dynamically detect concurrent unsynchronized memory accesses during test execution. The most tempting distractor, go vet, performs only static analysis and cannot catch actual runtime data races.

    Read the full bite: What Go tool detects data races and how do you invoke it?

26. Question 26 of 30

    Why do unit tests inside src/ typically require #[cfg(test)] while integration tests in the top-level tests/ directory do not?

    • aThe tests/ directory contains modules that are inlined into lib.rs, so they share the library's conditional compilation flags and can omit #[cfg(test)].
    • bIntegration tests are compiled into the same crate as the library, allowing them to test private functions without needing #[cfg(test)].
    • cIntegration tests must use #[cfg(test)] because Cargo does not automatically isolate them from cargo build.
    • dUnit tests need #[cfg(test)] because they live inside the library crate, whereas integration tests in tests/ are compiled as separate crates only during testing.
    Show the answer

    Answer: d · Unit tests need #[cfg(test)] because they live inside the library crate, whereas integration tests in tests/ are compiled as separate crates only during testing.

    Unit tests reside within the library crate, so #[cfg(test)] is needed to exclude them from normal builds; integration tests in tests/ are separate crates compiled only during cargo test by Cargo convention. Option C is wrong because Cargo already isolates the tests directory, making the attribute unnecessary.

    Read the full bite: How does cargo differentiate unit and integration tests by location?

27. Question 27 of 30

    On macOS, which command produces a pure Go ARM64 Linux binary in the current directory?

    • ago build after installing gcc-arm-linux-gnueabihf and QEMU
    • bGOOS=arm64 GOARCH=linux go build
    • cGOOS=linux GOARCH=arm64 go install
    • dGOOS=linux GOARCH=arm64 go build
    Show the answer

    Answer: d · GOOS=linux GOARCH=arm64 go build

    go build leaves the compiled binary in the current directory, whereas go install moves it to $GOBIN. Pure Go cross-compilation requires only GOOS and GOARCH; external C cross-compilers or QEMU are unnecessary.

    Read the full bite: Difference between go build and go install? Cross-compile for ARM64 Linux?

28. Question 28 of 30

    You add an optional dependency libwebp-sys to your crate. Which statement accurately describes how consumers can enable it and how it affects compilation?

    • aConsumers enable it by default unless they pass --no-default-features, and you must define a [features] table entry mapping webp to libwebp-sys
    • bConsumers enable it by adding features = ["libwebp-sys"] to their dependency, and your code can gate WebP support with #[cfg(feature = "libwebp-sys")]
    • cYou must use the dep:libwebp-sys prefix in your [features] table to expose the optional dependency as a feature
    • dConsumers enable it at runtime via an environment variable, and the linker includes the native library only when the variable is set
    Show the answer

    Answer: b · Consumers enable it by adding features = ["libwebp-sys"] to their dependency, and your code can gate WebP support with #[cfg(feature = "libwebp-sys")]

    Optional dependencies implicitly create a Cargo feature with the same name, so consumers enable them via features = [...] and authors gate code with #[cfg(feature = ...)]. The dep: prefix is used to hide or group optional dependencies behind custom feature names, not to expose them.

    Read the full bite: Explain Cargo features and how to define and enable them

29. Question 29 of 30

    Which combination correctly implements memory-efficient, line-by-line streaming for a multi-gigabyte file in Go and Rust?

    • aGo: os.ReadFile then split by newlines; Rust: File::open and call read_line directly without BufReader
    • bGo: bufio.Scanner with ScanLines, checking scanner.Err() after the loop; Rust: BufReader with read_line into a reused String buffer
    • cGo: bufio.Scanner with ScanLines, skipping scanner.Err(); Rust: BufReader.lines() collected into a Vec<String>
    • dGo: bufio.NewReader with ReadString by newline; Rust: fs::read_to_string then split lines
    Show the answer

    Answer: b · Go: bufio.Scanner with ScanLines, checking scanner.Err() after the loop; Rust: BufReader with read_line into a reused String buffer

    Go's bufio.Scanner streams lines with a hidden buffer but requires an explicit scanner.Err() check after the loop, while Rust's BufReader paired with read_line and a reused String avoids per-line allocations. Distractor D is tempting because it names the right types, yet skipping scanner.Err() misses I/O errors and collecting lines into a Vec<String> loads the entire file into RAM, defeating streaming.

    Read the full bite: Compare efficient line-by-line file reading in Go and Rust

30. Question 30 of 30

    Which statement accurately contrasts the ergonomics of propagating an I/O error up the call stack in Go and Rust?

    • aRust's Result is essentially syntactic sugar for checked exceptions, providing the same runtime behavior as Go's error tuples with different syntax.
    • bGo's defer statement can propagate errors up the stack similarly to Rust's ? operator, but requires manual wrapping with fmt.Errorf.
    • cGo requires explicit if err != nil checks and manual return statements, while Rust's ? operator can propagate a compatible Result with minimal boilerplate.
    • dGo's compiler will refuse to build code that discards an error return, while Rust permits ignoring a Result unless it is explicitly marked with must_use.
    Show the answer

    Answer: c · Go requires explicit if err != nil checks and manual return statements, while Rust's ? operator can propagate a compatible Result with minimal boilerplate.

    Go makes error checking explicit and voluntary, allowing callers to ignore the error tuple, whereas Rust's Result and ? operator enforce propagation or handling at compile time. Option D is tempting because it sounds like a plausible enforcement story, but it reverses the two languages: Go does not stop you from discarding errors, while Rust warns or errors on an unhandled Result.

    Read the full bite: Compare Go's error tuples to Rust's Result for I/O