When a Go type must own a background goroutine and a channel, why can't its zero value be usable, and what do you expose instead?

## Why this type is different from the map case A struct whose only awkward member is a map can usually be rescued: create the map on first write and the zero value works again. A type that owns a running goroutine cannot be rescued the same way, for two separate reasons. **The failure is silent.** A nil map panics on write — loud, immediate, with a stack trace pointing at the line. A nil channel does the opposite: a send blocks forever, a receive blocks forever, and a `select` case on a nil channel is simply never ready, which is the standard trick for disabling a case. So a caller who writes `var w Watcher` and then `w.events <- e` gets a goroutine that parks and never returns. Nothing is logged. The only symptom is a goroutine count that climbs, and the only diagnostic that finds it is a goroutine profile or a `SIGQUIT` stack dump. A design whose misuse produces a hang is worse than one whose misuse produces a panic. **There is nothing running.** Even if you lazily created the channel, the loop that drains it does not exist. Starting it from inside a method means an ordinary call now spawns a goroutine with no obvious owner, no error return if setup fails, and no defined point at which it stops. Lifetime is the part callers must be told about, and the type declaration cannot tell them. ## The shape to expose ```go // Watcher delivers events until Close is called. // The zero value is not usable; call NewWatcher. type Watcher struct { events chan string done chan struct{} } func NewWatcher() *Watcher { w := &Watcher{ events: make(chan string), done: make(chan struct{}), } go w.loop() return w } func (w *Watcher) Events() <-chan string { return w.events } func (w *Watcher) Close() { close(w.done) } ``` Four decisions are doing the work here. 1. **The constructor is the only correct path**, and it returns a pointer because the value owns a goroutine and must not be copied around as a value. 2. **The channel fields are unexported.** A caller in another package can still write `Watcher{}`, but cannot construct something that looks half-built, and cannot substitute their own channel. Unexported mandatory fields are how you make "you must use the constructor" close to enforceable without a language feature for it. 3. **The doc comment states the contract.** Nothing in a Go type declaration says whether zero works. The standard library's habit of writing either "the zero value is an empty X ready to use" or "call NewX" is the entire mechanism, and omitting it is the actual defect when someone later declares the type and hangs. 4. **There is a `Close`.** If the type starts a goroutine, the caller must be able to stop it, or every construction is a leak. Handing back a receive-only `<-chan string` from an accessor keeps the direction honest as well. ## When you want it to fail loudly instead If you cannot prevent misuse structurally — the type has to live in another package's struct, say — an explicit guard is defensible: ```go func (w *Watcher) Send(e string) { if w.events == nil { panic("watcher: Watcher must be created with NewWatcher") } ... } ``` A panic carrying the fix is strictly better than a hang, and it is the one case where deliberately panicking in a library is widely accepted: the program is misconfigured at construction, not failing at run time on data. ## The judgment being tested The interviewer is not asking whether you can spell `make(chan T)`. They are asking whether you rank failure modes when you design a type. The order to argue for is: make the zero value genuinely work if the members allow it; if they do not, force construction and document it; if the type can still be declared into existence, make that misuse crash with a message rather than hang. Applying a lazy-init reflex to a type that owns concurrency inverts that order, and the resulting bug shows up as a leaked goroutine in production rather than as a test failure.