What does unsafe enable in Go and Rust? List two operations.

What's really being asked

This question probes whether you understand the precise line between safe code and undefined behavior in memory-safe systems languages. Interviewers want to see that you know unsafe is not a generic escape hatch but a narrowly scoped tool with specific, well-defined powers. They also want to see if you can distinguish between Go's package-level approach and Rust's keyword-based approach.

The full answer

First, define the scope in each language. In Go, the unsafe package provides unsafe.Pointer and uintptr, which allow converting between arbitrary pointer types and performing pointer arithmetic; it does not disable the garbage collector or type system globally. In Rust, the unsafe keyword unlocks five specific capabilities: dereferencing raw pointers, calling unsafe functions including extern FFI blocks, implementing unsafe traits, accessing or mutating mutable static variables, and accessing fields of a union. Second, list two distinct operations that actually require unsafe, such as dereferencing a raw pointer in Rust and performing pointer arithmetic in Go, or calling a C library function across the FFI boundary in Rust while converting an arbitrary integer to a pointer in Go. Third, emphasize that safe abstractions can wrap unsafe internals, so end users never need to write unsafe themselves.

The mistakes people make

A major red flag is claiming that unsafe turns off the borrow checker, garbage collector, or all compiler checks; in Rust, safe invariants like ownership are still enforced even inside an unsafe block, and Go's runtime protections remain active. Another mistake is saying unsafe is purely for optimization or that it is always forbidden in production; many standard library features like split_at_mut or syscall wrappers rely on unsafe internally. Confusing the two languages is also risky, such as stating Rust uses an unsafe package or Go uses an unsafe keyword.

What usually comes next

The interviewer may ask how you would audit unsafe code for soundness, or what invariants you must manually uphold when using raw pointers. They might ask for an example of an unsafe abstraction you have written or consumed, or how Miri or Go's race detector helps catch errors that unsafe can introduce. A deeper follow-up is why Rust requires unsafe for FFI but Go does not, which touches on calling convention guarantees and runtime differences.

A concrete example

Consider implementing a zero-copy conversion from a byte slice to a string in Go. Using unsafe.Pointer, you can reinterpret the slice header as a string header because their runtime layouts share a data pointer and length, avoiding an allocation. In Rust, consider implementing SplitMut on a slice: you must use unsafe to create two mutable references from one slice, but you manually prove they do not overlap, wrapping the unsafe block inside a safe function so callers cannot violate the contract.