Go QA Notes - Kehao Zheng's Website

Questions and answers from learning Go syntax. These cover tricky concepts that aren’t immediately obvious from reading the guide.

Table of Contents#

Methods and Receivers
Pointers: * and &
Error Creation
Slices and Maps Initialization
if with Init Statement
defer
panic and recover
Goroutines
Channels
Mutex
sync.Once
Worker Pool Pattern
Buffered vs Unbuffered Channels

1. Methods and Receivers#

How do methods actually work?#

A method is just a regular function where Go automatically passes the “caller” as the first parameter:

1
// This method:
2
func (p Person) FullInfo() string {
3
    return fmt.Sprintf("%s (age %d)", p.Name, p.Age)
4
}
5

6
// Is essentially the same as this standalone function:
7
func FullInfo(p Person) string {
8
    return fmt.Sprintf("%s (age %d)", p.Name, p.Age)
9
}

The difference is how you call it:

1
alice := Person{Name: "Alice", Age: 30}
2

3
alice.FullInfo()       // method syntax — Go passes alice as `p`
4
FullInfo(alice)        // standalone function — you pass alice yourself

The (p Person) part between func and the method name “attaches” the function to the Person type. After that, every Person value gets .FullInfo() available on it.

Does defining a method add it to the type?#

Yes. You can keep adding methods to build up the type’s capabilities:

1
func (p Person) FullInfo() string { ... }
2
func (p Person) IsAdult() bool { ... }
3
func (p Person) Greet(other string) string { ... }

Now Person has three methods:

1
alice.FullInfo()        // "Alice (age 30)"
2
alice.IsAdult()         // true
3
alice.Greet("Bob")      // "Hi Bob, I'm Alice!"

This is how Go builds up types without classes — define a struct, then attach behavior one method at a time.

Value receiver vs pointer receiver#

The difference: a value receiver gets a copy, a pointer receiver gets the original.

1
// Value receiver — works on a copy
2
func (p Person) HaveBirthday() {
3
    p.Age++    // changes the COPY only
4
}
5

6
// Pointer receiver — works on the original
7
func (p *Person) HaveBirthdayForReal() {
8
    p.Age++    // changes the ORIGINAL
9
}

1
alice := Person{Name: "Alice", Age: 30}
2

3
alice.HaveBirthday()
4
fmt.Println(alice.Age)          // still 30 — the copy was modified, not alice
5

6
alice.HaveBirthdayForReal()
7
fmt.Println(alice.Age)          // 31 — alice herself was modified

Where does the modified copy go?#

Nowhere. It’s gone.

Go creates a copy of alice → p = Person{Name: "Alice", Age: 30}
Inside the method, p.Age++ → the copy now has Age: 31
The method returns → the copy is discarded

Nobody holds a reference to that copy. The Age: 31 value simply disappears. That’s why value receivers are useless for modification.

2. Pointers: `*` and `&`#

Why do `*` and `&` appear together in constructor functions?#

1
func NewBankAccount(owner string, initialDeposit float64) *BankAccount {
2
    return &BankAccount{
3
        Owner:   owner,
4
        Balance: initialDeposit,
5
        Active:  true,
6
    }
7
}

They do two different jobs:

*BankAccount — in the return type, means “I’m going to return a pointer to a BankAccount”
&BankAccount{...} — means “create a BankAccount and give me its address”

Think of it in two steps:

1
// Step 1: create a BankAccount value (lives somewhere in memory)
2
BankAccount{Owner: "Alice", Balance: 100, Active: true}
3

4
// Step 2: & takes its address (like writing down where it lives)
5
&BankAccount{Owner: "Alice", Balance: 100, Active: true}

Analogy:

1
*BankAccount       →  "a piece of paper with a house's address on it"
2
&BankAccount{...}  →  "build a house and write down its address on paper"

You can also write it in separate steps:

1
func NewBankAccount(owner string, initialDeposit float64) *BankAccount {
2
    account := BankAccount{       // create the value
3
        Owner:   owner,
4
        Balance: initialDeposit,
5
        Active:  true,
6
    }
7
    return &account               // return its address
8
}

3. Error Creation#

Is `errors.New()` the way to create a new error type?#

No — there are two different things:

errors.New() — creates a simple error value (not a new type):

1
var ErrNotFound = errors.New("not found")

This just creates a value that satisfies the error interface. It can only carry a fixed string message.

A custom struct — creates an actual new error type:

1
type ValidationError struct {
2
    Field   string
3
    Message string
4
}
5

6
func (e *ValidationError) Error() string {
7
    return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message)
8
}

This is a real new type. It satisfies the error interface because it has an Error() string method. The advantage: it can carry extra data that callers can inspect.

Approach	What it gives you
`errors.New("msg")`	A simple error with a fixed message
`fmt.Errorf("msg %d", val)`	A simple error with formatted message
Custom struct + `Error()` method	A rich error carrying extra data

4. Slices and Maps Initialization#

Why use `make` to create slices and maps?#

Slices — both literal and make work:

1
nums := []int{1, 2, 3}            // literal — when you know the values
2
nums := make([]int, 0, 100)       // make — when you'll fill it later

Maps — you MUST use make or a literal:

1
ages := map[string]int{"Alice": 30}    // literal — works
2
ages := make(map[string]int)            // make — works
3

4
var ages map[string]int
5
ages["Alice"] = 30    // PANIC! writing to a nil map

var ages map[string]int gives you a nil map. A nil map can be read (returns zero values) but panics if you write to it. make allocates the internal hash table so writes are safe.

Situation	Use
You know the values upfront	Literal: `[]int{1, 2, 3}`
You’ll fill it later, know the size	`make([]int, 0, size)`
You’ll fill it later, unknown size	`make([]int, 0)` or `make(map[string]int)`
Empty map you’ll write to	Must use `make` or `map[string]int{}`

5. `if` with Init Statement#

What does `if err := doSomething(); err != nil` mean?#

It’s two lines compressed into one. These are equivalent:

Long form:

1
err := doSomething()       // execute function, get err
2
if err != nil {            // check err
3
    fmt.Println("Error:", err)
4
    return
5
}
6
// err still exists here

Short form:

1
if err := doSomething(); err != nil {
2
    fmt.Println("Error:", err)
3
    return
4
}
5
// err does NOT exist here — scoped to the if block

The semicolon ; splits it into two parts:

1
if err := doSomething(); err != nil {
2
   ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^
3
   init statement           condition

The advantage: err only exists inside the if block, so you can reuse the name:

1
if err := step1(); err != nil {
2
    return err
3
}
4
// err is gone
5

6
if err := step2(); err != nil {    // no conflict
7
    return err
8
}

6. `defer`#

What is `defer`?#

defer means “run this later — when the function exits.”

1
func example() {
2
    fmt.Println("first")
3
    defer fmt.Println("deferred")
4
    fmt.Println("second")
5
}
6

7
// Output:
8
// first
9
// second
10
// deferred      ← runs last, right before the function returns

Why is it useful?#

It guarantees cleanup happens no matter how the function exits:

1
file, err := os.Open("data.txt")
2
if err != nil {
3
    return err
4
}
5
defer file.Close()    // guaranteed — runs no matter what happens below

Without defer, you’d have to call file.Close() before every return — easy to forget.

What is a resource leak?#

If you forget to close a file/connection, it stays open and occupies system resources. If this happens repeatedly (e.g., in a loop), you eventually run out and the program crashes with “too many open files.”

How to fix: Find where the resource is opened but never closed, and add defer Close().

How to prevent: Every time you see Open, Lock, Dial, or Acquire — the very next line should be defer Close/Unlock/Release.

7. `panic` and `recover`#

What is `panic`?#

panic = your program screams “something is terribly wrong!” and crashes.

1
func main() {
2
    fmt.Println("before panic")
3
    panic("everything is broken")
4
    fmt.Println("after panic")    // NEVER runs
5
}
6

7
// Output:
8
// before panic
9
// panic: everything is broken
10
// (program crashes)

When panic is called, the function immediately stops. No code after it runs. Use it only for bugs that should never happen — not for normal errors.

What is `recover`?#

recover = catch the panic before it crashes the program.

1
func safeCall() {
2
    defer func() {
3
        r := recover()       // catch the panic
4
        if r != nil {
5
            fmt.Println("caught a panic:", r)
6
        }
7
    }()
8

9
    panic("oh no!")          // would normally crash...but recover catches it
10
}

Step by step:

panic("oh no!") fires — function starts to exit
Before exiting, Go runs defer functions
Inside the deferred function, recover() catches the panic value
Because the panic was caught, the program doesn’t crash

Important: recover() only works inside a defer function.

Analogy:

1
panic   = pulling the fire alarm (everything stops)
2
recover = a firefighter catching it and saying "false alarm, carry on"

8. Goroutines#

What is a goroutine?#

A goroutine is like a thread — it means “do something at the same time.” (Technically lighter than OS threads, but mentally the same.)

Without goroutines — sequential (one at a time):

1
sayHello("Alice")     // wait until this finishes...
2
sayHello("Bob")       // then run this

With goroutines — concurrent (at the same time):

1
go sayHello("Alice")   // start this, DON'T wait for it
2
go sayHello("Bob")     // start this too, DON'T wait

go means: “start this function in the background, and immediately move to the next line.”

Why do we need `time.Sleep` or `WaitGroup`?#

When main returns, the program exits and kills all goroutines — even if they haven’t finished. You need something to keep main alive:

time.Sleep — crude, you’re guessing how long to wait
sync.WaitGroup — proper way, waits until all goroutines finish

1
var wg sync.WaitGroup
2

3
wg.Add(1)              // "1 goroutine starting"
4
go func() {
5
    defer wg.Done()    // "this goroutine finished"
6
    sayHello("Alice")
7
}()
8

9
wg.Wait()              // blocks until counter = 0

9. Channels#

What is a channel?#

A channel is a pipe between goroutines. One side puts something in, the other side takes it out.

1
ch := make(chan string)    // create a pipe that carries strings
2

3
go func() {
4
    ch <- "hello"          // put INTO the pipe
5
}()
6

7
msg := <-ch                // take OUT of the pipe (waits until something arrives)
8
fmt.Println(msg)           // "hello"

Why not just use a variable?#

Because goroutines run at the same time. Without a channel, you don’t know when the other goroutine is done writing:

1
// WITHOUT channel — broken:
2
var msg string
3
go func() {
4
    msg = "hello"         // when does this finish? who knows!
5
}()
6
fmt.Println(msg)          // might print "" — goroutine hasn't finished yet
7

8
// WITH channel — safe:
9
ch := make(chan string)
10
go func() {
11
    ch <- "hello"
12
}()
13
msg := <-ch               // WAITS until the goroutine sends
14
fmt.Println(msg)          // always prints "hello"

Unbuffered vs buffered?#

Unbuffered = hand-to-hand delivery. Sender waits until receiver is ready.

1
ch := make(chan string)     // no buffer — both sides must be present

Buffered = a mailbox with slots. Sender drops it off and leaves (until mailbox is full).

1
ch := make(chan string, 3)  // 3 slots — sender can drop off 3 without waiting

What is `select` with timeout?#

“Wait for a result, but give up after X seconds”:

1
select {
2
case result := <-ch:
3
    fmt.Println("Got result:", result)
4
case <-time.After(3 * time.Second):
5
    fmt.Println("Timed out!")
6
}

Whichever happens first wins. If the result arrives within 3 seconds, first case runs. If 3 seconds pass with no result, second case runs.

10. Mutex#

What happens when two goroutines access shared data at the same time?#

Without mutex — broken:

1
Goroutine A: reads count (0)
2
Goroutine B: reads count (0)      ← both read 0
3
Goroutine A: writes count = 1
4
Goroutine B: writes count = 1     ← should be 2, but it's 1! Lost an increment.

With mutex — safe:

1
Goroutine A: Lock() ✓ → reads count, increments, writes → Unlock()
2
Goroutine B: Lock() → WAITS... → A unlocks → B gets lock ✓ → reads, increments, writes

Only one goroutine holds the lock at a time. The other must wait.

`sync.Mutex` vs `sync.RWMutex`?#

Situation	`Mutex`	`RWMutex`
Multiple readers at once	No — one at a time	Yes — all read simultaneously
Reader + writer at once	No	No — one must wait
Multiple writers at once	No	No

RWMutex is an optimization: reading doesn’t corrupt data, so there’s no reason to block readers from each other. Only writing is dangerous.

How does Go know which goroutine gets the lock first?#

Whoever calls Lock()/RLock() first wins. It’s essentially random. But that’s fine — the mutex guarantees it doesn’t matter which order they run. Both orders are safe.

11. `sync.Once`#

What does `sync.Once` do?#

It ensures a function runs exactly once, even if called from multiple goroutines simultaneously.

1
var once sync.Once
2

3
func GetDatabase() *Database {
4
    once.Do(func() {
5
        instance = connectToDatabase()    // runs only the first time
6
    })
7
    return instance
8
}

1
Goroutine 1: calls GetDatabase() → once.Do runs connectToDatabase() ✓
2
Goroutine 2: calls GetDatabase() → once.Do sees "already ran" → skips
3
Goroutine 3: calls GetDatabase() → once.Do sees "already ran" → skips

Without sync.Once — race condition:

1
if instance == nil {               // two goroutines both check at the same time
2
    instance = connectToDatabase() // both connect — oops, connected twice!
3
}

Analogy: Opening a store. Ten employees arrive at the same time. Only one should unlock the door — the rest just walk in.

12. Worker Pool Pattern#

Walkthrough#

1
func main() {
2
    jobs := make(chan int, 100)       // to-do list (buffered)
3
    results := make(chan int, 100)    // finished pile (buffered)
4

5
    // Start 3 workers
6
    for w := 0; w < 3; w++ {
7
        go worker(jobs, results)
8
    }
9

10
    // Send 9 jobs
11
    for j := 0; j < 9; j++ {
12
        jobs <- j
13
    }
14
    close(jobs)
15

16
    // Collect results
17
    for r := 0; r < 9; r++ {
18
        fmt.Println(<-results)
19
    }
20
}
21

22
func worker(jobs <-chan int, results chan<- int) {
23
    for job := range jobs {
24
        results <- job * 2
25
    }
26
}

Step by step:

Create pipes — jobs for sending work to workers, results for getting answers back
Start 3 workers — each runs in the background, waiting at the jobs pipe
Send 9 jobs — numbers 0-8 go into the buffer
close(jobs) — tells workers “no more jobs coming”
Workers grab jobs — each takes the next available item from the buffer, computes job * 2, sends result
Collect results — main reads 9 values from results

The workers share the jobs channel. Only one worker gets each job — it’s like taking an item off a shelf (once taken, it’s gone).

How does `for job := range jobs` work?#

1
// This:
2
for job := range jobs {
3
    // use job
4
}
5

6
// Is the same as:
7
for {
8
    job, ok := <-jobs     // take from pipe
9
    if !ok {              // pipe closed and empty?
10
        break             // stop
11
    }
12
    // use job
13
}

The loop keeps grabbing jobs until the channel is closed and empty.

What are the results?#

Values: 0, 2, 4, 6, 8, 10, 12, 14, 16 (each job × 2). But the order is unpredictable because 3 workers run in parallel — whoever finishes first sends their result first.

13. Buffered vs Unbuffered Channels#

”Both seem the same — workers take items one by one either way?”#

From the worker’s perspective, yes — no difference. The difference is on the sender’s side:

Unbuffered — sender must wait for a worker to take each item:

1
Main sends 0 → waits... → worker takes it ✓
2
Main sends 1 → waits... → worker takes it ✓
3
Main sends 2 → waits... → worker takes it ✓
4
(9 waits total)

Buffered(100) — sender dumps everything instantly:

1
Main sends 0,1,2,3,4,5,6,7,8 → all go in buffer immediately, main moves on
2
Workers grab from buffer at their own pace

Analogy:

1
Unbuffered = hand-delivering tasks to workers one by one, waiting each time
2
Buffered   = putting all tasks on a table and walking away — workers help themselves

Is buffered always better?#

No. Unbuffered has one advantage: backpressure.

1
Buffered(1000): main sends 1000 jobs instantly.
2
  If workers are slow → 1000 items sit in memory → high memory usage.
3

4
Unbuffered: main is FORCED to slow down to workers' speed.
5
  Only sends the next job when a worker is free → low memory usage.

Use	When
Unbuffered	You want sender to slow down if receiver is behind (backpressure)
Unbuffered	You need confirmation the other side received it
Buffered	Sender and receiver work at different speeds
Buffered	You know the max items and don’t want sender to wait

Welcome