All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
4330 bites
Page 129
Rust binary and library crates in one project
A binary crate has main and produces an executable; a library crate has lib.rs and is reusable; put logic in the lib and a thin main that calls it.
What is the purpose of the internal directory in Go?
Tests Go visibility boundaries beyond exported vs unexported. A strong answer states that internal is compiler-enforced module privacy, while lowercase is only package-private. Red flag: calling internal a naming convention rather than a build boundary.
Explain the difference between mod and use in Rust
Mod tells the compiler to compile a file into the crate tree; use brings an existing path into scope as a shortcut.
Rust workspace versus single crate for plugins
A workspace gives incremental compilation, enforced API boundaries via a shared api crate, and per-plugin deps; a single crate is simpler but recompiles wholesale and blurs boundaries.
Describe Go's memory management, garbage collection, and trade-offs
Explain Go's GC recycles heap memory, the compiler stack-allocates locals, and automatic collection costs runtime overhead.
Explain Rust's Ownership and its three compiler-enforced rules
Tests your grasp of Rust's compile-time memory model. A strong answer lists the three ownership rules, links them to stack versus heap, and notes borrow checking enforces them at compile time. Red flag: calling it manual memory management.
Why are Rust's borrowing rules stricter than Go's pointers?
This tests compile-time versus runtime safety tradeoffs. A strong answer contrasts Go's aliasing with Rust's rule of one mutable or many immutable references to prevent data races without a GC. A red flag is calling Rust strict without citing race prevention.
Rust borrow rules versus Go race prevention
Rust's aliasing-XOR-mutability rule plus Send and Sync make races a compile error; Go prevents them at runtime via channels, mutexes and the race detector.
How does Rust ownership avoid Go GC's non-deterministic pauses?
Tests if you know Rust's compile-time ownership eliminates GC pauses by making deallocation deterministic at scope boundaries. A strong answer contrasts Go's STW with Rust's immediate Drop and zero-cost compile-time checks.
Explain Go escape analysis and Rust ownership for stack vs heap
Tests compiler-driven memory placement. Go escape analysis keeps non-escaping locals on stack, shrinking heap and GC work. Rust ownership lets the compiler pick stack or heap at build time with zero cost.
Explain Rust Rc and Arc versus Go's tracing GC
This tests deterministic reference counting versus tracing GC. A strong answer contrasts Rc's heap reference counts with Go's root tracing, and notes Rc cannot reclaim cycles while Go's GC can. Red flag: claiming Rc has no cycle leak risk.
Rust unsafe FFI vs Cgo: who owns memory safety?
Tests your grasp of where compiler guarantees end at the FFI boundary. A strong answer contrasts Rust raw-pointer validity and aliasing invariants in unsafe blocks against Cgo's automatic copying, pointer-passing restrictions, and runtime thread-switching…
How do you idiomatically return a recoverable error and result in Go?
This tests Go's multiple-return error idiom. A strong answer gives a (T, error) signature with error last, returns nil on success, and checks err before using the result. A red flag is suggesting panic for recoverable errors or pointer out-parameters.
What are Rust Result's variants and how does the compiler enforce handling?
This tests Rust's explicit error model. A strong answer names Ok(T) and Err(E), explains must_use warns when Results are ignored, and notes pattern matching or ? is required to extract values.
Rust's operator equivalent to Go's if err != nil return err
Tests if you know Rust's ? operator for error propagation. A strong answer names ?, explains it returns Err from the function via Result's Try and FromResidual traits, and unwraps Ok. Red flag: calling it .unwrap() or suggesting manual match is idiomatic.
Difference between errors.Is and errors.As in Go
This tests error-chain inspection in Go. errors.Is checks sentinel equality through wrapping, such as os.ErrNotExist. errors.As extracts a custom type, like os.PathError, into a variable. A red flag is using direct == or type assertions on wrapped errors.
What is the difference between unwrap and expect on Option and Result?
It tests your Rust error-handling discipline and justified panics. Both extract values or panic, but expect adds a custom message. Use them only for unrecoverable invariant violations, not routine errors. A red flag is using them as lazy error propagation.
How does the question mark operator use From to unify error types?
This tests Rust error conversion mechanics. You define a unified enum error and implement From for each source error so ? automatically converts via From::from. A red flag is suggesting manual match or map_err on every call instead of trait-based conversion.
Design a custom Go error type with context, Is, As, and Unwrap
This tests Go 1.13 error wrapping and Unwrap conventions. Answer: struct with Err and context fields; implement Error and Unwrap; note errors.Is and errors.As walk the chain. Red flag: stringifying the error via fmt.Errorf %v, which severs unwrapping.
When to panic in Go versus Rust
Both reserve panic for unrecoverable bugs and use values, Result or error, for expected failures; Rust's type system pushes more cases to Result.