Ошибка	Последствие
Запустить `go f()` и сразу вернуться из `main`	Программа завершится, горутина не успеет отработать — вывода не будет
Отправить в небуферизированный канал, когда никто не принимает	Горутина блокируется навсегда; если это `main` — `deadlock` и аварийный выход
Считать `make(chan T)` и `make(chan T, 1)` одинаковыми	Без буфера отправка ждёт приёмника; с буфером на 1 одна отправка проходит сразу
Вызвать `wg.Add(1)` внутри уже запущенной горутины	`Wait()` может увидеть нулевой счётчик и выйти раньше — гонка; `Add` делают до `go`
Забыть `wg.Done()` в одной из горутин	Счётчик не дойдёт до нуля, `Wait()` зависнет навсегда
Закрыть канал на стороне читателя	Паника при отправке в закрытый канал; закрывать должен только отправитель
Принимать из закрытого канала и не проверять `ok`	Получите нулевое значение типа и примете его за настоящее

beginner

Goroutines & Channels

Starting a goroutine with `go`, sending and receiving over a channel, the difference between buffered and unbuffered channels, waiting with `sync.WaitGroup`, and draining a channel with `range`/`close`.

go-goroutines-intro

Practice: 5 questions →

Sections

Contents

Detailed explanation

Goroutines & Channels

Concurrency is built into Go at the language level: you start a parallel task with the single keyword go, and you exchange data between such tasks through channels — typed "pipes" with built-in synchronisation. This is the intro topic: its goal is to start a goroutine, pass values in and out, and wait for completion cleanly, without diving into how the scheduler works.

Behind the apparent simplicity sit a few rules that interviews probe at the junior level. A goroutine is a lightweight thread managed by the Go runtime, not the operating system; when main returns, the program exits and all remaining goroutines are cut off. A send ch <- v to an unbuffered channel blocks the goroutine until the other side does a receive <-ch — so the channel also synchronises. To wait for a group of goroutines you use sync.WaitGroup. And when the writer is done, it calls close(ch), and the reader calmly walks the channel with for v := range ch. We take the topic layer by layer — from starting up to closing a channel. The scheduler design, select, and concurrency patterns are out of scope here — they live in the Concurrency and Channels topics.

Topic map

The go keyword — go f() starts a goroutine — a lightweight runtime-managed thread; it runs concurrently, and returning from main cuts off all goroutines at once.
Send & Receive — a channel is a typed "pipe" make(chan T); ch <- v sends, v := <-ch receives; a send to an unbuffered channel blocks until someone receives (basic synchronisation).
Buffered vs Unbuffered — make(chan T, n) sets capacity n; an unbuffered channel (capacity 0) synchronises each send with a receive, while a buffered send blocks only when the buffer is full.
sync.WaitGroup — Add(n) before starting, Done() (usually via defer) in each goroutine, Wait() blocks until the counter hits zero — the canonical way to wait for a group of goroutines.
range & close — close(ch) signals "no more values"; for v := range ch drains the channel until closed; receiving from a closed channel yields the zero value and ok=false; only the sender closes.

Common mistakes and traps

Mistake	Consequence
Starting `go f()` and immediately returning from `main`	The program exits before the goroutine runs — there is no output
Sending to an unbuffered channel when nobody receives	The goroutine blocks forever; if it is `main`, a `deadlock` and a fatal exit
Treating `make(chan T)` and `make(chan T, 1)` as the same	Without a buffer a send waits for a receiver; with a buffer of 1 one send goes through right away
Calling `wg.Add(1)` inside an already-started goroutine	`Wait()` may see a zero counter and exit early — a race; do `Add` before `go`
Forgetting `wg.Done()` in one of the goroutines	The counter never reaches zero and `Wait()` hangs forever
Closing the channel on the reader side	A panic on a send to a closed channel; only the sender should close
Receiving from a closed channel without checking `ok`	You get the type's zero value and mistake it for a real one

Why it matters for interviews

Goroutines and channels are an almost mandatory block of a Go junior section: interviews start with them because this is the language's "feature." Deep scheduler knowledge is not expected at this level, but the basic mechanics of starting and synchronising are asked every time.

What interviewers usually check:

What go f() does and why a goroutine is "lightweight" — it is managed by the Go runtime, not the OS.
Why a program with go fmt.Println(...) in main often prints nothing (returning from main cuts off goroutines).
How a send to an unbuffered channel differs from a buffered one and what "the channel blocks" means.
How to wait for several goroutines with sync.WaitGroup and why Add goes before go.
Who calls close and why, what a receive from a closed channel yields, and how a for range over a channel ends.

Why it matters

Concurrency is Go's signature feature, and the junior section almost always opens with it. Starting a goroutine with a single `go` is easy, but that simplicity hides exactly the traps newcomers fall into: `main` returns and every goroutine is cut off before it prints anything; a send to an unbuffered channel blocks until someone receives; `WaitGroup.Add` placed after `go` lets `Wait` race ahead; the wrong side closes the channel. This is the bare minimum to start a goroutine, exchange values, and wait for completion; the scheduler internals and `select` come later.

Ошибка	Последствие
Запустить `go f()` и сразу вернуться из `main`	Программа завершится, горутина не успеет отработать — вывода не будет
Отправить в небуферизированный канал, когда никто не принимает	Горутина блокируется навсегда; если это `main` — `deadlock` и аварийный выход
Считать `make(chan T)` и `make(chan T, 1)` одинаковыми	Без буфера отправка ждёт приёмника; с буфером на 1 одна отправка проходит сразу
Вызвать `wg.Add(1)` внутри уже запущенной горутины	`Wait()` может увидеть нулевой счётчик и выйти раньше — гонка; `Add` делают до `go`
Забыть `wg.Done()` в одной из горутин	Счётчик не дойдёт до нуля, `Wait()` зависнет навсегда
Закрыть канал на стороне читателя	Паника при отправке в закрытый канал; закрывать должен только отправитель
Принимать из закрытого канала и не проверять `ok`	Получите нулевое значение типа и примете его за настоящее

beginner

Goroutines & Channels

go-goroutines-intro

Practice: 5 questions →

Sections

Contents

Detailed explanation

Goroutines & Channels

Topic map

The go keyword — go f() starts a goroutine — a lightweight runtime-managed thread; it runs concurrently, and returning from main cuts off all goroutines at once.
Send & Receive — a channel is a typed "pipe" make(chan T); ch <- v sends, v := <-ch receives; a send to an unbuffered channel blocks until someone receives (basic synchronisation).
Buffered vs Unbuffered — make(chan T, n) sets capacity n; an unbuffered channel (capacity 0) synchronises each send with a receive, while a buffered send blocks only when the buffer is full.
sync.WaitGroup — Add(n) before starting, Done() (usually via defer) in each goroutine, Wait() blocks until the counter hits zero — the canonical way to wait for a group of goroutines.
range & close — close(ch) signals "no more values"; for v := range ch drains the channel until closed; receiving from a closed channel yields the zero value and ok=false; only the sender closes.

Common mistakes and traps

Mistake	Consequence
Starting `go f()` and immediately returning from `main`	The program exits before the goroutine runs — there is no output
Sending to an unbuffered channel when nobody receives	The goroutine blocks forever; if it is `main`, a `deadlock` and a fatal exit
Treating `make(chan T)` and `make(chan T, 1)` as the same	Without a buffer a send waits for a receiver; with a buffer of 1 one send goes through right away
Calling `wg.Add(1)` inside an already-started goroutine	`Wait()` may see a zero counter and exit early — a race; do `Add` before `go`
Forgetting `wg.Done()` in one of the goroutines	The counter never reaches zero and `Wait()` hangs forever
Closing the channel on the reader side	A panic on a send to a closed channel; only the sender should close
Receiving from a closed channel without checking `ok`	You get the type's zero value and mistake it for a real one

Why it matters for interviews

What interviewers usually check:

What go f() does and why a goroutine is "lightweight" — it is managed by the Go runtime, not the OS.
Why a program with go fmt.Println(...) in main often prints nothing (returning from main cuts off goroutines).
How a send to an unbuffered channel differs from a buffered one and what "the channel blocks" means.
How to wait for several goroutines with sync.WaitGroup and why Add goes before go.
Who calls close and why, what a receive from a closed channel yields, and how a for range over a channel ends.

Why it matters

Горутины и каналы

Горутины и каналы

Карта темы

Частые ошибки и ловушки

Значение для собеседований

Goroutines & Channels

Goroutines & Channels

Topic map

Common mistakes and traps

Why it matters for interviews

Горутины и каналы

Горутины и каналы

Карта темы

Частые ошибки и ловушки

Значение для собеседований

Goroutines & Channels

Goroutines & Channels

Topic map

Common mistakes and traps

Why it matters for interviews