Go vs. Rust: Why String Indexing Is Tricky

Why it exists

The term "character" is ambiguous. A string is stored as a sequence of bytes, but a single visual character (like 'é' or 'न') can be one or more bytes. Languages must provide a way to access string data that is both efficient and safe, forcing a tradeoff between convenience and correctness.

The mental model

Think of a UTF-8 string as a byte array. Go gives you direct, unchecked access to this array, like a key to a room full of parts. Rust acts as a security guard, asking for your intent before letting you in: "Do you want the raw bytes, or do you want the assembled Unicode characters?" This prevents you from accidentally grabbing half a character.

How it works

Go's approach prioritizes simplicity. Indexing a string, s[i], accesses the i-th byte. A standard for loop iterates byte by byte. For character-aware iteration, Go provides a special for...range loop that decodes one UTF-8 rune (a code point) at a time. Slicing a Go string is a byte-level operation and can create invalid UTF-8 if a slice boundary splits a multi-byte character.

Rust's approach prioritizes safety. Direct indexing is a compile-time error. To iterate, you must be explicit: s.bytes() for bytes or s.chars() for Unicode scalar values (code points). Slicing is allowed (&s[..i]), but it will cause the program to panic at runtime if the slice boundary is not on a valid character boundary. For true visual characters (grapheme clusters), you need an external crate like unicode-segmentation.

When to use it

In Go, use the for...range loop for almost all string iteration. Use byte indexing only when you are certain you are dealing with raw bytes or pure ASCII.

In Rust, use .chars() for iterating over Unicode code points and .bytes() when interacting with byte-level protocols. Slicing is safe if the indices are derived from string search functions, which guarantee valid boundaries.

When not to use it

Never use simple index-based loops or slicing (s[i], s[i:j]) on Go strings that may contain multi-byte characters. You risk corrupting data or getting nonsensical results.

In Rust, avoid slicing with hardcoded or calculated integer offsets unless you have validated them. This is a common source of panics.

One canonical example

For the string s = "नमस्ते": In Go, s[0] returns 224, the first byte of the character 'न'. A for...range loop correctly yields the runes for 'न', 'म', 'स', etc. In Rust, attempting s[0] fails to compile. s.chars() correctly iterates over the code points. Slicing with &s[..2] panics because the byte at index 2 is in the middle of a character.