Compare Go string and Rust &str/String types, mutability, UTF-8, ownership

WHAT THIS TESTS: The interviewer wants to know if you can reason about memory layout, aliasing, and mutability tradeoffs across language boundaries. Specifically, they are checking whether you understand that Go uses a single string type with value semantics and immutable backing data, while Rust splits the concern into a borrowed view and an owned container. This reveals whether you think in terms of ownership, borrowing, and UTF-8 validity guarantees.

A GOOD ANSWER COVERS: Four things in order. First, Go string is a two-word header holding a pointer to immutable UTF-8 bytes and a length; it is read-only by design, so operations like concatenation always allocate new memory. Second, Rust str is an unsized primitive type almost always seen as &str, which is a fat pointer to a contiguous UTF-8 slice that you can borrow immutably but never modify through that reference. Third, Rust String is a growable, heap-allocated buffer that owns its UTF-8 data and can be mutated only by its sole owner; it derefs to str so methods are shared. Fourth, both enforce UTF-8 validity at the type level, but Go strings are cheap to copy because they are small headers, whereas Rust String moves ownership by default and copying requires explicit clone.

COMMON WRONG ANSWERS: Five red flags. One, saying Go strings are mutable; they are not, and the language runtime treats string data as read-only. Two, claiming Rust &str is a pointer to a String; it can point to any UTF-8 bytes, including string literals and slices into a String. Three, stating that Rust String is copy-on-write like some other languages; it is uniquely owned. Four, confusing Rust string slices with Go slices; a Go slice is a separate type with a cap field, while Rust &str is a borrow with no capacity. Five, forgetting that both languages reject invalid UTF-8 in their standard string types, though Rust exposes from_utf8 for fallible construction while Go relies on string conversions from rune slices or validated byte slices.

LIKELY FOLLOW-UPS: The interviewer may ask how string concatenation differs, so be ready to explain that Go uses the plus operator with allocation, while Rust uses push_str on an owned String or the format macro. They might ask about interior mutability or unsafe string construction, which opens discussion about from_utf8_unchecked in Rust or unsafe pointer casting in Go. They could also ask about OsString versus String in Rust, or why Go lacks a distinct mutable string buffer type, which leads to the builder pattern or byte slice mutation before final conversion.

ONE CONCRETE EXAMPLE: Imagine receiving a text payload in both languages. In Go, you get a string header pointing into the HTTP body bytes; if you need to uppercase it, you allocate a new string because the original is immutable. In Rust, you might receive a &str from a parser; to accumulate tokens, you create a mutable String and push string slices into it, with the borrow checker ensuring the original &str and the new String never alias mutably. This shows how Go simplifies the model at the cost of hidden allocations, while Rust makes ownership and mutation explicit.