Goroutines

A regular call

This runs to completion before main continues. Nothing concurrent yet.

package main

import "fmt"

func greet(who string) {
	fmt.Println("hello,", who)
}

func main() {
	greet("alice")
	greet("bob")
}

Spawn it as a goroutine

Prefix the call with go. The function now runs in a new goroutine, and main continues immediately. Both calls are scheduled, but there's no guarantee they finish — main might return first and tear down the process.

func main() {
	go greet("alice")
	go greet("bob")
	// main returns here. The runtime may or may not have
	// scheduled the goroutines yet.
}

Wait with a WaitGroup

sync.WaitGroup is the smallest primitive for "wait for N goroutines to finish." Call Add before spawning, Done inside each goroutine, Wait to block until the counter hits zero.

package main

import (
	"fmt"
	"sync"
)

func greet(who string, wg *sync.WaitGroup) {
	defer wg.Done()
	fmt.Println("hello,", who)
}

func main() {
	var wg sync.WaitGroup
	for _, name := range []string{"alice", "bob", "carol"} {
		wg.Add(1)
		go greet(name, &wg)
	}
	wg.Wait()
}

Why not just use threads?

Goroutines share an address space, so passing data between them is just passing a value. The runtime's scheduler handles context switching cooperatively at safe points (channel ops, syscalls, function calls with stack growth). The result is that idiomatic Go code spawns goroutines liberally — one per incoming request, one per pipeline stage, one per timer — without the per-thread overhead you'd worry about in C or Java.

The catch is that goroutines see the same memory. Two goroutines writing to the same map without synchronization will corrupt it. The fix is almost never a lock; it's a channel.