Rune Vs Byte
Fast recall
Quick revision
Core answer
Whether you understand Rune Vs Byte beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
A byte is Go's smallest integer (uint8 — one raw byte). A rune is Go's Unicode code point (int32). In strings they compose via UTF-8: a string is a byte sequence where each rune is 1-4 bytes.
The numbers, executed:
s := "héllo"
len(s) // 6 — BYTES (h, é=2 bytes, l, l, o)
utf8.RuneCountInString(s) // 5 — RUNES
s[1] // 195 — first byte of é's 2-byte encoding
[]rune(s)[1] // 233 — the rune é itselfASCII hides the difference (1 byte = 1 rune); anything international breaks the naive assumption. s[i] is a byte value; []rune(s)[i] is a code point (after an O(n) conversion — the cost).
The iteration distinction: for i, r := range s yields RUNES with BYTE-offset indices — i jumps by encoding width. Executed: héllo gives i=0 (h), i=1 (é), then i=3 (l — é occupied 2 bytes). A raw loop over len(s) sees meaningless half-rune values at é's position.
The mistake this catches: len(s) as 'character count.' It's byte count. Character count is utf8.RuneCountInString — or don't count: range already yields each rune once.
Rune Vs Byte
Direct Answer
A byte (uint8) = one raw memory byte. A rune (int32) = one Unicode code point. ASCII: 1 byte = 1 rune. Beyond ASCII (é, emoji): one rune encodes as MULTIPLE bytes — len(s) counts bytes, utf8.RuneCountInString(s) counts runes.
Deep Dive & Architecture
The UTF-8 encoding behind every fact here: code points 0-127 encode as 1 byte (ASCII). 128-2047 as 2. 2048-65535 as 3 (most CJK). 65536+ as 4 (emoji). The first byte's high bits announce the width (0xxxxxxx = 1 byte; 110xxxxx = 2; 1110xxxx = 3; 11110xxx = 4) — how range decodes without lookups, and why a mid-rune byte can never look like a start.
The rune type's identity: rune IS int32 — an alias, not a distinct type. It exists as documentation: 'this int32 means a code point.' byte IS uint8 — same relationship. The types are vocabulary; the semantics are UTF-8's.
Why not a fixed-width 'char' like Java's UTF-16: UTF-8 is the network/file format already (zero conversion at IO boundaries); ASCII (the common case) pays 1 byte/char instead of 2 or 4; the variable-width cost is confined to code that needs character logic (range, []rune, utf8) while byte-oriented code pays nothing. The trade: make Unicode explicit over making everything pay for it.
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Rune Vs Byte in a real project?
- What is a common mistake when using Rune Vs Byte?
- How would you compare Rune Vs Byte with an alternative?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.