Go data types

Go Data Types: Slices, Maps, and Numeric Pitfalls

Octal Literals (#17)

• Integer literals starting with 0 are octal (base 8). 010 == 8, not 10.
• Always use the explicit 0o prefix for octal numbers to prevent confusion:

// Bad - readers may think this is decimal 644
file, err := os.OpenFile("foo", os.O_RDONLY, 0644)

// Good - explicitly octal
file, err := os.OpenFile("foo", os.O_RDONLY, 0o644)

• Other literal prefixes: 0b (binary), 0x (hex), i suffix (imaginary).
• Use _ as a digit separator for readability: 1_000_000_000.

Integer Overflows (#18)

• Integer overflow and underflow are silent at runtime in Go. No panic occurs.
• Compile-time overflow (e.g., var x int32 = math.MaxInt32 + 1) is caught, but runtime overflow is not.
• When overflow matters (conversions, large numbers, constrained integer sizes), guard explicitly:

// Increment
func Inc32(counter int32) int32 {
    if counter == math.MaxInt32 {
        panic("int32 overflow")
    }
    return counter + 1
}

// Addition
func AddInt(a, b int) int {
    if a > math.MaxInt-b {
        panic("int overflow")
    }
    return a + b
}

// Multiplication
func MultiplyInt(a, b int) int {
    if a == 0 || b == 0 {
        return 0
    }
    result := a * b
    if a == 1 || b == 1 {
        return result
    }
    if a == math.MinInt || b == math.MinInt {
        panic("integer overflow")
    }
    if result/b != a {
        panic("integer overflow")
    }
    return result
}

• Use math/big when int64 is insufficient.

Floating Points (#19)

• float32 and float64 are approximations (IEEE-754). They cannot represent all decimal values exactly.
• Never compare floats with ==. Compare within a delta:

// Bad
if f1 == f2 { ... }

// Good
const epsilon = 1e-9
if math.Abs(f1-f2) < epsilon { ... }

• Floating-point error accumulates across operations. To reduce it:
  • Addition/subtraction: group values of similar magnitude together.
  • Mixed operations: perform multiplication and division before addition and subtraction.

// Better accuracy: add small values first, then add large value
result := 0.0
for i := 0; i < n; i++ {
    result += 1.0001
}
result += 10_000.0

// Better accuracy: multiply/divide before add/subtract
// Prefer: a*b + a*c  over  a*(b+c) when magnitudes differ

• Special values: +Inf, -Inf, NaN. Check with math.IsInf, math.IsNaN.
• NaN is the only float where f != f is true.

Slice Length vs. Capacity (#20)

• Length: number of accessible elements. Capacity: size of backing array.
• make([]int, 3, 6) creates a slice with length 3, capacity 6.
• Accessing beyond length panics even if capacity allows it; use append to grow into capacity.
• When capacity is exhausted, append allocates a new backing array (doubles until 1024 elements, then grows ~25%).
• Slicing (s1[1:3]) shares the backing array. Mutations via one slice are visible through the other.
• After enough appends cause a new backing array, the slices decouple.

Inefficient Slice Initialization (#21)

• If the output length is known, always preallocate:

// Bad - causes repeated allocations and copies
bars := make([]Bar, 0)
for _, foo := range foos {
    bars = append(bars, fooToBar(foo))
}

// Good (fastest) - given length + direct index
bars := make([]Bar, len(foos))
for i, foo := range foos {
    bars[i] = fooToBar(foo)
}

// Good (slightly slower, sometimes more readable) - given capacity + append
bars := make([]Bar, 0, len(foos))
for _, foo := range foos {
    bars = append(bars, fooToBar(foo))
}

• Given-length is ~4% faster than given-capacity due to avoiding append overhead.
• Use given-capacity + append when index math would be complex (e.g., two appends per iteration).
• If exact length is unknown but an upper bound exists, prefer setting capacity to the upper bound.

Nil vs. Empty Slices (#22)

• A nil slice (var s []string): s == nil is true, len(s) == 0.
• An empty slice (s := []string{} or make([]string, 0)): s == nil is false, len(s) == 0.
• Nil slice requires zero allocation. Prefer var s []T when the slice may remain empty.
• append works on nil slices. No need to defensively initialize to non-nil.
• Do not return non-nil empty slices for defensive reasons. Return nil slices instead.

// Good - returns nil if nothing appended (zero allocation)
func f() []string {
    var s []string
    if foo() { s = append(s, "foo") }
    if bar() { s = append(s, "bar") }
    return s
}

• Avoid []string{} without initial elements; it allocates unnecessarily.
• Beware: encoding/json marshals nil slices as null and empty slices as []. reflect.DeepEqual distinguishes nil from empty. Know your downstream consumers.

Initialization cheat sheet:

Form	Nil?	When to use
var s []T	yes	Default; final length unknown, may be empty
[]T(nil)	yes	Inline nil slice (e.g., append([]int(nil), 42))
make([]T, n)	no	Known length
make([]T, 0, n)	no	Known capacity, use with append
[]T{}	no	Only when providing initial elements

Checking if a Slice is Empty (#23)

• Always check len(s) == 0, never s == nil.
• len works correctly for both nil and non-nil empty slices.
• Same rule applies to maps: check len(m) == 0, not m == nil.
• When designing APIs, do not distinguish between nil and empty slices.

Slice Copy (#24)

• copy(dst, src) copies min(len(dst), len(src)) elements. A zero-length dst copies nothing.

// Bug - dst is zero-length, copies nothing
var dst []int
copy(dst, src)

// Correct
dst := make([]int, len(src))
copy(dst, src)

• Argument order: destination first, source second.
• Alternative one-liner: dst := append([]int(nil), src...).

Unexpected Side Effects with Append (#25)

• Appending to a sub-slice can mutate the original slice's backing array if capacity remains:

s1 := []int{1, 2, 3}
s2 := s1[1:2]         // len=1, cap=2, shares backing array
s3 := append(s2, 10)  // overwrites s1[2]! s1 is now [1, 2, 10]

• Fix option 1: pass a copy of the sub-slice.
• Fix option 2 (preferred): use a full slice expression to cap capacity:

// s[:2:2] creates a slice with len=2, cap=2
// append will allocate a new backing array instead of mutating
f(s[:2:2])

• When passing sub-slices to functions that may append, always use the full slice expression s[low:high:max].

Slices and Memory Leaks (#26)

Capacity leak

• Slicing a large slice (e.g., msg[:5] from a 1MB slice) retains the entire backing array.
• The GC cannot reclaim the unused portion. Full slice expressions (msg[:5:5]) do not help here.
• Fix: copy into a new slice:

func getMessageType(msg []byte) []byte {
    msgType := make([]byte, 5)
    copy(msgType, msg)
    return msgType
}

Pointer element leak

• When slicing a slice of pointers (or structs with pointer fields), the GC does not reclaim elements outside the new length but inside the original backing array.
• Fix option 1: copy the elements you need into a new slice.
• Fix option 2: nil out excluded elements before slicing:

func keepFirstTwo(foos []Foo) []Foo {
    for i := 2; i < len(foos); i++ {
        foos[i].v = nil  // allow GC to collect backing data
    }
    return foos[:2]
}

• Choose based on proportion: if keeping few elements, copy; if discarding few, nil them out.

Inefficient Map Initialization (#27)

• Go maps are backed by hash table buckets (8 elements each). Maps grow by doubling buckets, requiring rehashing all keys.
• If the number of entries is known, always provide a size hint:

// Bad - causes repeated growth and rehashing
m := make(map[string]int)

// Good - preallocates buckets for ~1M entries
m := make(map[string]int, 1_000_000)

• Providing a size hint is ~60% faster for large maps vs. not providing one.
• The size is a hint, not a hard limit. You can still add more elements.
• Unlike slices, maps take only a single size argument to make (no separate capacity).

Maps and Memory Leaks (#28)

• Map buckets never shrink. Deleting all entries does not free bucket memory.
• After adding 1M entries and deleting them all, the map retains its bucket structure.
• This matters for maps that experience high-water-mark spikes (e.g., caches during peak load).
• Mitigation strategies:
  1. Periodically re-create the map: build a new map, copy live entries, release the old one.
  2. Use pointer values (map[K]*V instead of map[K]V) to reduce per-bucket memory. Buckets still exist but each slot stores only a pointer (8 bytes) instead of the full value.
• Values or keys over 128 bytes are automatically stored as pointers by the runtime.

Comparing Values (#29)

• == works on: booleans, numerics, strings, channels, interfaces, pointers, and structs/arrays composed entirely of comparable types.
• == does not work on slices, maps, or structs containing them. This is a compile error.
• Comparing any-typed values containing non-comparable types panics at runtime.

var a any = customer{operations: []float64{1.0}}
var b any = customer{operations: []float64{1.0}}
fmt.Println(a == b) // PANIC at runtime

• reflect.DeepEqual: works for all types but is ~100x slower than ==. Distinguishes nil from empty slices. Best for tests.
• Custom equal method: ~96x faster than reflect.DeepEqual. Preferred for runtime comparison of non-comparable structs.
• bytes.Compare: optimized for []byte comparison. Check standard library before writing custom comparators.
• In tests, prefer go-cmp or testify over reflect.DeepEqual for better diffs and readability.