Why can't you assign to s[0] on a Go string, and what do you do instead?

### The rule A Go string is an **immutable** sequence of bytes. Once a string value exists, nothing in the language can change its contents. `s[0] = 'G'` is not a runtime failure or an undefined behaviour — it is a compile error, because `s[0]` is a value, not a storage location. For the same reason `&s[0]` does not compile: there is nothing addressable to point at. This catches out anyone arriving from a language where a string, or its byte buffer, can be poked in place. ### Why the language works this way Immutability buys several properties that Go leans on heavily: - **Free sharing.** Assigning a string, passing it to a function, or storing it in a struct never needs a defensive copy, because no holder can modify it. - **Cheap substrings.** `s[a:b]` is a substring expression that does not need to copy the text, precisely because neither the substring nor the original can be written to. - **Safe map keys.** A string can be a map key; a mutable key would corrupt the map the moment someone changed it after insertion. - **Predictable concurrency.** A string handed to another goroutine cannot be mutated out from under it, which removes an entire class of data race. The cost is that every edit produces a new value. ### How to change text **Editing ASCII — go through a byte slice.** ``` b := []byte(s) b[0] = 'G' s = string(b) ``` The conversion `[]byte(s)` produces a **new, mutable slice holding a copy** of the bytes; `string(b)` copies them back into a new immutable string. The round trip therefore costs two copies, which matters in a hot loop and is invisible in ordinary code. **Editing non-ASCII — go through a rune slice.** ``` r := []rune(s) r[3] = 'e' s = string(r) ``` `[]rune(s)` decodes the UTF-8 into a slice of code points, so index 3 means "the fourth character", not "the fourth byte". Converting back re-encodes. This is the conversion to reach for whenever the position you care about is a character position — with a byte slice, writing at index 3 of `"José"` would overwrite half of the accented letter and leave the string invalid. Note also that the replacement character need not have the same encoded width as the one it replaces, so the new string can be shorter or longer in bytes than the old one. That is another reason the operation has to build a new value rather than patch the existing one. **Building rather than editing.** Most "modify a string" tasks are really "produce a new string": concatenation, `strings.Replace`-style substitution, or accumulating pieces. Repeated `s += piece` in a loop allocates a fresh string on every iteration; `strings.Builder` exists to accumulate text without that cost. ### Immutability is not deep for byte slices The symmetry is worth stating: a `[]byte` **is** mutable, and converting from one to the other copies in both directions specifically so that mutating the slice cannot be observed through the string. If conversions shared memory, writing to the slice would silently change a value that other code believes is frozen — which is exactly the guarantee the language is protecting. ### What an interviewer is checking Three things, usually: that you know the assignment is rejected at compile time rather than tolerated; that you can name the byte-slice round trip and its cost; and that you pick `[]rune` rather than `[]byte` when the edit is positioned by character. The third is the one that separates someone who has only handled ASCII from someone who has shipped text handling. ### A practical note If you find yourself doing byte-slice round trips repeatedly on the same value — building a result character by character, say — the answer is usually to keep the working form as a slice for the whole operation and convert to a string once at the end, rather than converting on every step. One conversion in and one out is the shape to aim for.