Why are Rust's borrowing rules stricter than Go's pointers?

WHAT THIS TESTS: The interviewer wants to know if you understand that Rust's borrowing rules are not bureaucratic syntax but a compile-time strategy to guarantee memory safety and data-race freedom without a garbage collector. Go can afford multiple mutable pointers to the same data because it has a garbage collector that cleans up memory and because Go's race detector finds some data races at runtime. Rust removes the GC and replaces runtime checks with compile-time proofs.

A GOOD ANSWER COVERS: First, explain that a reference in Rust is a borrow: it lets you access data without taking ownership, and the data is guaranteed valid for the reference's lifetime. Second, state the core rule: at any moment, a value may have either exactly one mutable reference or any number of immutable references, but never both simultaneously. Third, connect this to Go: Go pointers are free to alias and mutate because Go relies on garbage collection and runtime tooling to catch issues, trading performance and compile-time guarantees for flexibility. Fourth, emphasize the benefit: Rust's rule prevents data races, iterator invalidation, and use-after-free bugs at compile time with zero runtime overhead.

COMMON WRONG ANSWERS: A red flag is claiming Rust is stricter just to be difficult or because it is newer. Another mistake is confusing borrowing with ownership: saying you cannot have multiple pointers in Rust at all is wrong; you can have many immutable ones. A third error is asserting that Go is safer because it is more permissive; safety and permissiveness are different axes, and Rust chooses static verification over runtime freedom.

LIKELY FOLLOW-UPS: The interviewer may ask what happens if you try to create a mutable reference while immutable references exist, or how interior mutability types like RefCell or Mutex relax these rules in controlled ways. They might also ask how this compares to C++ const references or whether Rust's borrow checker can ever be bypassed with unsafe code.

ONE CONCRETE EXAMPLE: Imagine a function that appends text to a shared string buffer. In Go, you can pass multiple pointers to the same slice to different goroutines; if they write concurrently, you get a data race that the GC will not prevent. In Rust, the compiler rejects code that tries to hold an immutable reference for printing while also passing a mutable reference to an append function. You must either scope the mutable borrow so it ends before the immutable ones are used, or restructure the code to clone the data. This forces the race to be resolved before the program runs.