Forem: Ponlamai

🤨 Go Quiz — Slices, Pointers, Structs & Decimal

Ponlamai — Wed, 06 May 2026 06:13:33 +0000

A collection of Go quizzes to test your understanding of slices, pointers, structs, and decimals. Try to answer before revealing each answer!

Slice #1

func main() {
    var a []int
    for i := 1; i <= 5; i++ {
        a = append(a, i)
        fmt.Printf("%p, %p, %d, %d\n", &a, &a[0], len(a), cap(a))
    }
}

Question

Consider the result of line 5 for each iteration.

Will the address of a be identical?
Will the address of a[0] be identical?
What is the expected len(a)?
What is the expected cap(a)?

Answer

0xc000010018, 0xc000012028, 1, 1
0xc000010018, 0xc000012050, 2, 2
0xc000010018, 0xc00007a020, 3, 4
0xc000010018, 0xc00007a020, 4, 4
0xc000010018, 0xc00007c040, 5, 8

The address of a (the slice header) is always the same — the variable itself doesn't move.
The address of a[0] changes when the backing array is reallocated (capacity exceeded).
cap doubles each time a reallocation happens: 1 → 2 → 4 → 8.

Reference: https://go.dev/blog/slices-intro

Slice #2

func main() {
    a := []int{1, 2, 3, 4, 5, 6, 7}
    b := make([]int, 5, 5)
    for _, i := range a {
        b = append(b, i)
    }
    fmt.Println(b, len(b), cap(b))   // line 7
    fmt.Println(b[19])               // line 8
    c := b[:20]
    fmt.Println(c, len(c), cap(c))   // line 10
    c[11] = 99
    fmt.Println(b, c)                // line 12
    c[19] = 99
    fmt.Println(b, c)                // line 14
}

Question

Determine the expected output of lines 7, 8, 10, 12, 14.

Answer

// line 7:  [0 0 0 0 0 1 2 3 4 5 6 7] 12 20
// line 8:  panic!
// line 10: [0 0 0 0 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0] 20 20
// line 12: b=[0 0 0 0 0 1 2 3 4 5 6 99]  c=[0 0 0 0 0 1 2 3 4 5 6 99 0 0 0 0 0 0 0 0]
// line 14: b=[0 0 0 0 0 1 2 3 4 5 6 99]  c=[0 0 0 0 0 1 2 3 4 5 6 99 0 0 0 0 0 0 0 99]

b starts at length 5, then 7 elements appended → length 12, capacity doubles: 5 → 10 → 20.
b[19] panics — index 19 exceeds len(b)-1 (11).
c := b[:20] is valid because 20 ≤ cap(b). c shares the same backing array as b.
Mutating c[11] also changes b[11] — same backing array.
Mutating c[19] does NOT show on b — index 19 is beyond len(b).

Slice #3

Clinical test for re-slicing!

func main() {
    x := []int{1, 2}
    fmt.Println(x[2:])
    x = append(x, 3)
    fmt.Println(x[:4])
}

Question

Will it panic? If yes, which line? If not, what is the result?

Answer

No panic.

Line 3 → [] (valid: 2 <= len(x))
Line 5 → [1 2 3 0] (valid: 4 <= cap(x) after append)

Slice expressions satisfy 0 <= low <= high <= cap(arr), not just len.

Reference: https://go.dev/ref/spec#Slice_expressions

Pointer #1

type A struct { Name string; Age int }
type B struct { Name *string; Age *int }

var a = []A{{"john", 18}, {"danny", 19}, {"carl", 20}}

func main() {
    var b []B
    for _, v := range a {
        b = append(b, B{Name: &v.Name, Age: &v.Age})
    }
    for _, v := range b {
        fmt.Println(*v.Name, *v.Age)
    }
}

Question

What is the expected output of the second loop?

Answer

carl 20
carl 20
carl 20

The loop variable v is reused each iteration — its address is identical every time. All entries in b point to the same address, which holds the last value.

Fix: reference the original slice element by index.

for i := range a {
    b = append(b, B{Name: &a[i].Name, Age: &a[i].Age})
}

Pointer #2

func main() {
    var a *int
    *a = 111
    fmt.Println(*a)
}

Question

What is the expected output?

Answer

Panic — a is nil. Dereferencing a nil pointer causes a runtime panic.

func main() {
    var a *int
    b := 1
    a = &b
    *a = 111
    fmt.Println(*a) // 111
}

Struct #1 (and Pointer)

type counter struct{ I int }

func (d *counter) inc() { d.I++ }
func NewCounter(in int) *counter { return &counter{I: in} }
func A(d counter) { d.inc() }
func B(d *counter) { d.inc() }

func main() {
    c := NewCounter(0)
    fmt.Println("start", c.I)
    A(*c); A(*c); A(*c)
    fmt.Println("result from A is", c.I)
    B(c); B(c); B(c)
    fmt.Println("result from B is", c.I)
}

Question

What is the expected output?

Answer

start 0
result from A is 0
result from B is 3

A receives a copy — mutations don't affect the original.
B receives a pointer — mutations affect the original.

Struct #2 (and Interface)

type counter struct{ I int }

func (d counter) inc() { d.I++ }
func NewCounter(in int) *counter { return &counter{I: in} }

type ICounter interface{ inc() }
func dofunc(d ICounter) { d.inc() }

func main() {
    c := NewCounter(0)
    fmt.Println("start", c.I)
    dofunc(*c); dofunc(*c)
    fmt.Println("result from A is", c.I)
    dofunc(c); dofunc(c)
    fmt.Println("result from B is", c.I)
}

Question

Can we pass either struct or pointer-to-struct to dofunc? What is the output?

Answer

Yes, both compile — but the result is always 0. inc is a value receiver, so every call gets a copy.

start 0
result from A is 0
result from B is 0

Fix: change inc to a pointer receiver func (d *counter) inc() and pass only the pointer.

Reference: https://stackoverflow.com/questions/44370277/type-is-pointer-to-interface-not-interface-confusion

Decimal

func main() {
    v1 := decimal.NewFromInt(100)
    var v2 decimal.Decimal
    if v2 != decimal.Zero {           // line 4
        fmt.Println(v1.Div(v2))
    }
    if v2.Cmp(decimal.Zero) != 0 {   // line 8
        fmt.Println(v1.Div(v2))
    }
}

Question

Between line 4 and line 8, which properly prevents dividing by zero?

Answer

Line 8 — using .Cmp().

decimal.Decimal is a struct. Using != compares field-by-field and can give unexpected results. Always use .Cmp(decimal.Zero) != 0 to compare decimal values correctly.

ID Capacity — The Math Behind Choosing the Right ID Length

Ponlamai — Fri, 01 May 2026 07:32:00 +0000

The main aim of this article is to describe the limitations of ID, in terms of capacity, and the math behind the scene.

Alright, good people — ID is not complicated. Various methods can generate it, such as using a counting number, randomizing, or composing/concatenating from multi-attributes (like a national ID or college student ID). Sometimes one can ignore it because the ID is auto-generated in the database, like MongoDB.

But what if we must find out how to make the ID as short as possible? That is why we need to take time for consideration.

The Proper ID Properties

Let's think about the important properties of ID.

No duplication — no need to elaborate. If the ID is not unique, it is not an ID.
It must be sufficient — in terms of capacity, it depends on the generation method. Assume the system will contain no more than 100 records. If the ID is generated by a running number, 2 digits of decimal is fine (00–99). In contrast, the same 2 digits are not sufficient if the ID is generated by randomizing.
It can't be guessed — if someone got the ID 95, by intuition, everybody knows there are also IDs 1, 2, …, 94. They also know there are 95 records of data. This makes the system so transparent — and you will feel very insecure if the ID is sensitive data.
It should not be too long — this property is necessary if we intend the user to memorize their ID; otherwise, just ignore it.
Efficient to create. ID generation should not be the bottleneck of the system. It should consume a very short time and satisfy all properties above.
1. The running number is far away from the good option because it can only be processed one by one which means it has to wait for the current one to be created before the next one can be processed.
2. Composing from multi-attributes is edgy to violate the property numbers 2 and 3. For example, an employee ID like ENG-2024-001 (department + year + sequence). It can be guessed for sure. One can tell the department, the join year, and roughly how many employees there are.
3. Rely on auto-generated methods like UUID or let the database generate for us, these methods work well for most of the use-case except a system which may use ID as the referral code for inviting new members. The referral code should not be too long while the real question is how many digits of ID that enough?

ID Collision Probability

To find the proper digit count for a randomized-generated ID, we must know the chance that a newly created one will duplicate any existing ID.

Thanks to mathematics (even though we do not get along so well) back in 1939 that explains this in a lot more simple terms the birthday problem. In short, they state that only 23 people are needed for that probability, for at least two will share a birthday, to exceed 50%. The statement is considered a paradox which seems wrong, but it's true.

⚠️ Warning, math inside!

Birthday Problem Explanation

The explanation is from Wikipedia — Birthday Problem

Define n as the number of 23 people
There are 2 types of events for this problem.
Assume A is the probability that none in the group share the same birthday.
While B is the probability that at least 2 people share a birthday.
Determine the value of A is more simple than B because people who shared the same birthday might be 2, 3,…, 23 people plus a lot of combinations, for example, there might be 1, 2,… pairs of people that share their own birthday.
We know that A + B = 1
Assume that a year has 365 days. Let P1 be the arrangement that all 23 people have different birthdays while P2 is all possible arrangements.
- P2 = 365^23
- P1 = P(365,23) = 365!/(365-23)! = 365 x 364 x 363 x … x (365-22)
A = P1 / P2 = 365/365 x 364/365 x 363/365 x … x (365-22)/365 ~ 0.492703
B = 1 - A ~ 0.507297, yeah it is 50.7297%

There are various probability estimation methods that I won't explain (cause I don't fully understand them 🥹) for the real-world application.

By the way, you don't need to understand the math behind for estimation of the collision probability. Thanks to some nice guys, they created the calculator for mankind! Please find the link below.

👉 https://zelark.github.io/nano-id-cc/

We may define a set of possible alphabet and the number of characters of ID. Plus expected ID generation rate per time then the tool will estimate the lifespan of the ID we designed.

Note: Collision chance grows exponentially, so 1% is a relatively safe magic number to indicate the capacity limit of the ID generation.

collision chance of the birthday problem

The UUID We Trust

One question: how long can we actually use UUID?

Since everyone says UUID is trustworthy, I'm just curious — how long can we ignore the fact that it's theoretically possible for UUID to reach its limit?

For those who don't know, UUID is 32 characters of hexadecimal. Plugging that into the calculator gives a truly extraordinary answer — UUIDs are effectively unlimited for any realistic use case.

UUID collision chance

Now, good people ~Your entire image is crafted to leave no lasting memory with anyone you encounter!

Consideration

Now we know there is a small collision chance in randomized ID generation — so what now?

We may either:

Handle the relatively low possible collision error, or
Ignore it because the deadline is too rushed 😅

The decision is yours!