Lectures

We break down channels in Go as the basic communication mechanism for goroutines: the type chan T, creation via make( chan T), and the dangers of a nil channel. We learn two operations — sending ch <- v and receiving <- ch — understand the “handshake” of an unbuffered channel, the reasons for deadlock, and common mistakes when designing a send/receive protocol.

We break down the behavior of channels in Go: what makes an unbuffered channel different (a strict “handshake” and synchronization) from a buffered one (a queue and a shifted blocking point), when send/ receive operations block, how to interpret len/ cap, why “buffer size 1” is sometimes needed to keep a goroutine from getting stuck, and which common mistakes lead to unexpected blocking.

Let’s break down how to properly finish a data stream in Go by closing a channel: what exactly close( ch) does (and does not do), who should close the channel, how reads behave after closing, and how to distinguish “real data” from “end of stream” using the form v , ok := <- ch. Plus: scenarios with multiple senders (a coordinator + WaitGroup) and a list of common mistakes that lead to panic.

We break down why reading a channel with for range means reading “until the stream ends”, how this is equivalent to the v , ok := <- ch idiom, and why you need the protocol “one producer sends and that same producer does close ( ch )”. We will also show why an unclosed channel leads to a “silent hang”, and how to embed the data-streaming pattern into application code.

We break down why in Go you may want to “narrow permissions” on channels in a public API: how to use chan <- T (send-only) and <- chan T (receive-only), why direction is part of the type, who should call close, and how to design stream-style functions that return only a read-only channel.