compare Rune Vs Byte with an alternative
Fast recall
Quick revision
Core answer
Practical understanding of Rune Vs Byte.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
Two counts, two units:
s := "héllo"
len(s) // 6 — bytes: h(1) é(2) l(1) l(1) o(1)
utf8.RuneCountInString(s) // 5 — runes: h é l l oExecuted. ASCII makes them equal (1 byte per rune); any multibyte content diverges them.
len is the honest capacity of what's stored (the string's header field — O(1), no walking). RuneCountInString decodes the whole string, counting code points — O(n). That cost difference matters in hot paths: len is free, rune-count walks everything.
Which to use, by job: byte-count for capacity/protocol limits (wire format sizes are bytes); rune-count for display width logic (approximately — runes aren't exactly screen columns, but closer than bytes); range for anything that also processes the characters (it counts and works in one pass — no separate count).
The bug pattern: a character-limit validator using len(s) — a 10-character emoji-heavy input fails at ~40 bytes. The fix: RuneCountInString, or validate while ranging (count as you go — one O(n) either way, no double pass).
compare Rune Vs Byte with an alternative
Direct Answer
len(s) = BYTES in the string. utf8.RuneCountInString(s) = RUNES (characters). Same only for pure ASCII. 'héllo': len 6, runes 5.
Deep Dive & Architecture
The two counters' mechanics: len(s) reads the string header's length field (a stored value — that's WHY it's O(1); the count was paid once, at construction). utf8.RuneCountInString iterates and decodes — it's a loop the standard library wrote for you, with the same self-synchronizing walk range uses.
Why 'rune count = character count' is itself approximate: a code point is not a user-perceived character (a grapheme cluster — what users call a character — can be MULTIPLE code points: é can be e + combining accent (2 runes), skin-tone emoji compose from several runes). Go's rune count counts code points, not graphemes — closer than bytes, still not display columns. For true display width: libraries like rivo/uniseg segment graphemes. Interview honesty: state that rune count is the code-point count and name the grapheme distinction — that's the depth signal.
The three-level summary that frames all the string-counting questions: bytes (storage — len), runes (code points — RuneCountInString), graphemes (user characters — third-party segmenters). Every 'how long is this string' question is really 'which unit do you mean' — and APIs that must be exact specify (wire limits: bytes; UI limits: graphemes).
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is Rune Vs Byte, and when would you use it?
- When would you use Rune Vs Byte in a real project?
- What is a common mistake when using Rune Vs Byte?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.