Value vs Reference Semantics

JavaScript: everything object is a reference

In JavaScript and TypeScript, all non-primitive values (objects, arrays, functions) are passed by reference. Assigning an object to a new variable does not copy it — both variables point at the same data.

// TypeScript — objects always share
const a = { x: 1 };
const b = a;        // b points to the SAME object
b.x = 99;
console.log(a.x);   // 99 — a was also mutated

In Go, the rules are more nuanced: some types copy, some share. Knowing which is which prevents subtle bugs.

Structs and arrays are value types

Assigning a struct or fixed-size array to a new variable produces a full copy. Modifying the copy does not touch the original.

// TypeScript — objects always share (reference)
interface Point { x: number; y: number; }
const a: Point = { x: 1, y: 2 };
const b = a;      // b is the SAME object
b.x = 99;
console.log(a.x); // 99 — mutated!

// Arrays also share:
const arr1 = [1, 2, 3];
const arr2 = arr1;
arr2[0] = 99;
console.log(arr1[0]); // 99

// Go — structs copy on assign
type Point struct{ X, Y int }

a := Point{X: 1, Y: 2}
b := a          // b is a full COPY
b.X = 99
fmt.Println(a.X) // 1 — a is unchanged

// Fixed-size arrays also copy
arr1 := [3]int{1, 2, 3}
arr2 := arr1    // copy
arr2[0] = 99
fmt.Println(arr1[0]) // 1 — unchanged

Slices and maps are reference types

Slices and maps hold an internal pointer to their underlying data. Assigning them to a new variable shares that pointer — both variables refer to the same underlying array or hash table.

// TypeScript — arrays (like all objects) are references
const s1 = [1, 2, 3];
const s2 = s1;    // same array
s2[0] = 99;
console.log(s1[0]); // 99

// Maps too:
const m1 = new Map([["a", 1]]);
const m2 = m1;
m2.set("a", 99);
console.log(m1.get("a")); // 99

// Go — slices share the underlying array
s1 := []int{1, 2, 3}
s2 := s1        // s2 shares s1's underlying array
s2[0] = 99
fmt.Println(s1[0]) // 99 — shared!

// Maps always share
m1 := map[string]int{"a": 1}
m2 := m1
m2["a"] = 99
fmt.Println(m1["a"]) // 99 — shared!

// To get a true copy, use copy() for slices:
s3 := make([]int, len(s1))
copy(s3, s1)
s3[0] = 0
fmt.Println(s1[0]) // 99 — s1 unchanged

Passing to functions

The same rules apply when passing values to functions. Struct arguments arrive as copies; slice/map arguments share the header.

// TypeScript — objects always pass by reference
function mutate(obj: { x: number }) {
  obj.x = 99;    // mutates caller's object
}
const p = { x: 1 };
mutate(p);
console.log(p.x); // 99

// Go — struct passes as copy; mutation doesn't affect caller
func mutateStruct(p Point) {
    p.X = 99    // modifies the LOCAL copy only
}

// Slice passes its header (pointer + len + cap) — shares data
func mutateSlice(s []int) {
    s[0] = 99   // modifies the shared underlying array
}

func main() {
    pt := Point{X: 1}
    mutateStruct(pt)
    fmt.Println(pt.X) // 1 — unchanged

    sl := []int{1, 2, 3}
    mutateSlice(sl)
    fmt.Println(sl[0]) // 99 — shared data modified
}

Try it

Open in Playground

package main

import "fmt"

type Point struct{ X, Y int }

func tryMutateStruct(p Point) {
  p.X = 999
}

func tryMutateSlice(s []int) {
  s[0] = 999
}

func main() {
  // Struct: value copy
  pt := Point{X: 1, Y: 2}
  tryMutateStruct(pt)
  fmt.Println("struct after func:", pt.X) // 1 — unchanged

  // Slice: reference semantics
  sl := []int{1, 2, 3}
  tryMutateSlice(sl)
  fmt.Println("slice after func:", sl[0]) // 999 — mutated

  // Array (fixed size): value copy
  arr := [3]int{10, 20, 30}
  arr2 := arr
  arr2[0] = 999
  fmt.Println("array original:", arr[0]) // 10 — unchanged

  // Explicit deep copy of slice
  original := []int{1, 2, 3}
  clone := make([]int, len(original))
  copy(clone, original)
  clone[0] = 999
  fmt.Println("original after clone mutation:", original[0]) // 1
}

🟦 Slice Header — Three Fields Under the Hood

A slice is not a simple pointer. Internally it is a small struct with three fields:

type sliceHeader struct {
    Data *[N]T  // pointer to the underlying array
    Len  int    // number of elements
    Cap  int    // capacity of the underlying array
}

When you assign a slice to another variable, Go copies this header — so both variables share the same Data pointer. That is why element mutations are visible through both. However, append may allocate a new underlying array when capacity is exceeded, at which point the two headers diverge and modifications stop being shared. This is a subtle but important distinction.

a := []int{1, 2, 3}
b := a
b = append(b, 4, 5, 6, 7) // likely causes a new allocation
b[0] = 99
fmt.Println(a[0]) // may still be 1 — b may have a new backing array

🟦 nil Slice vs Empty Slice

A nil slice (var s []int) and an empty slice (s := []int{}) behave identically for most operations — len(s) is 0 for both, range s iterates zero times — but they are NOT equal. A nil slice has a nil Data pointer; an empty slice has a non-nil Data pointer to a zero-length array. When marshalling to JSON, json.Marshal encodes a nil slice as null and an empty slice as []. This distinction matters in API responses.

var nilSlice []int
emptySlice := []int{}
fmt.Println(nilSlice == nil)   // true
fmt.Println(emptySlice == nil) // false