Explains how Go's go keyword launches goroutines and scheduler basics

The article shows that placing go before a function call starts a goroutine without blocking the caller, a change from the explicit thread creation or pool configuration required in languages like Java or Python. This removes the need to allocate a thread object, size a pool, or import a concurrency library. The only cost is a small stack and a runtime bookkeeping structure, which is far cheaper than an OS thread. However, if the main function returns before the scheduler runs the goroutine, its output is lost, so the simple go statement alone does not guarantee completion.

Unlike an OS thread, which reserves a full megabyte-scale stack and requires a system call for each creation, a goroutine begins with a 2 KB stack that grows as needed and is created entirely inside the process. The Go runtime schedules many goroutines onto a small number of OS threads using an m:n model, so the kernel only sees the underlying threads. Context switches between goroutines stay in user space, avoiding the expense of a kernel transition. The GOMAXPROCS variable limits how many OS threads can run Go code in parallel, shaping the actual parallelism achievable.

A common first attempt to keep the program alive is to insert a fixed time.Sleep, but this relies on guessing the workload duration and can waste time or still miss output. The correct approach is to use a sync.WaitGroup, which increments a counter for each launched goroutine and blocks the caller until the counter reaches zero. This synchronization adds negligible overhead while providing deterministic waiting. Channels can also be used, but the excerpt focuses on WaitGroup as the primary tool for simple wait-until-done patterns.

Other runtimes have adopted similar lightweight concurrency models, Erlang’s processes and Java’s virtual threads in JDK 21, but Go ties the model to a single keyword, making it the default unit of concurrency. The design still depends on the operating system for actual thread execution, so programs that block on system calls may need more OS threads than GOMAXPROCS allows to stay productive. For pure CPU-bound work, increasing GOMAXPROCS raises parallelism, but the scheduler’s m:n nature means excessive goroutine counts can increase context-switch overhead without gaining more CPU time.