go-expert

Go Expert

Clear is better than clever. Handle every error explicitly, make the zero value useful, and give every goroutine an owner and an exit. "Share memory by communicating," but a Mutex is fine for protecting state.

When to Use

• Writing or refactoring Go.
• Designing concurrent code (goroutines, channels, context, select).
• Data races, deadlocks, goroutine leaks, or context propagation bugs.
• Package layout, interfaces, and standard-library usage.

When NOT to Use

• Other languages → the relevant language skill.
• System-level architecture → software-architect.

Core Principles

1. Errors are explicit values

• Check immediately: if err != nil { return fmt.Errorf("doing X: %w", err) }. Wrap with %w to preserve the chain; inspect with errors.Is (sentinel) / errors.As (typed).
• Add context at each layer ("opening config: …") but don't double-log the same error. Return errors up; log once at the boundary.
• Panic only for truly unrecoverable programmer errors, never for normal control flow.

2. Interfaces & types

• Accept interfaces, return concrete types. Keep interfaces small (often one method) and define them in the consumer package, not the producer.
• Make the zero value useful (sync.Mutex, bytes.Buffer work unboxed). Use defer for cleanup (close/unlock) right after acquisition.

3. Concurrency with ownership

• Every goroutine needs a clear lifetime and exit path — leaks are silent. Use sync.WaitGroup or errgroup to wait, and bound concurrency (errgroup.SetLimit, worker pool, semaphore).
• context.Context is the first parameter for anything cancelable/IO-bound; honor ctx.Done(). Never store a Context in a struct.
• Channels for handoff/signaling; Mutex for protecting shared state. Close a channel from the sender, once. Prefer select with ctx for cancelable waits.

4. Tooling & structure

• gofmt (non-negotiable), go vet, golangci-lint. Always test concurrent code with -race.
• Organize by capability; keep private code under internal/. Avoid premature interfaces and needless abstraction.