Goroutines & Channels — Concurrency Without the JVM's Baggage

In part 2 I went through Go's type system — structs, implicit interfaces, and composition replacing inheritance entirely. This time I'm tackling the thing that actually pulled me toward Go in the first place: concurrency.

If you've spent years on the JVM like I have, "concurrency" usually means a mental checklist — ExecutorService, thread pool sizing, Future<T>, maybe CompletableFuture chains, and more recently virtual threads if you're on a modern JDK. It's powerful, but it's also a lot of ceremony for what's often a simple idea: "do these things at the same time, then collect the results." Go strips almost all of that ceremony away, and that's been the most genuinely refreshing part of this whole learning process.

Goroutines: Threads, But Cheap

A goroutine is Go's unit of concurrent execution. The syntax is almost suspiciously simple — you put go in front of a function call, and it runs concurrently:

func main() {
    go sayHello("world")
    time.Sleep(50 * time.Millisecond) // give it time to run
}

func sayHello(name string) {
    fmt.Println("Hello,", name)
}

That time.Sleep hack is the first lesson everyone learns the hard way: main doesn't wait for goroutines to finish. If main exits, every goroutine it spawned just gets cut off mid-flight. We'll fix that properly in a moment with sync.WaitGroup, but the sleep hack is worth seeing once because it makes the "goroutines don't block their caller" behavior concrete.

What makes goroutines genuinely different from JVM threads isn't the syntax — it's the cost. A JVM thread typically reserves around a megabyte of stack space and is managed by the OS scheduler. A goroutine starts with a stack of about 2KB that grows as needed, and Go's own runtime scheduler multiplexes thousands of them onto a small number of OS threads. Spinning up 100,000 goroutines is a normal thing to do in Go. Spinning up 100,000 JVM platform threads will bring most systems to their knees — which is exactly the problem virtual threads were introduced to solve in recent JDKs. Go just had this answer from day one.

WaitGroups: The Right Way to Wait

Instead of sleeping and hoping, sync.WaitGroup lets you wait for a known number of goroutines to actually finish:

func main() {
    var wg sync.WaitGroup

    services := []string{"orders", "payments", "inventory"}

    for _, name := range services {
        wg.Add(1)
        go func(s string) {
            defer wg.Done()
            fetchFromService(s)
        }(name)
    }

    wg.Wait()
    fmt.Println("all services responded")
}

func fetchFromService(name string) {
    time.Sleep(100 * time.Millisecond)
    fmt.Println(name, "done")
}

wg.Add(1) registers one goroutine to wait for, defer wg.Done() marks it complete when the function returns, and wg.Wait() blocks until the count hits zero. Notice the name is passed as a parameter into the closure rather than captured directly — that's intentional. Capturing the loop variable directly is a classic Go footgun (pre-1.22, every closure would share the same variable and you'd get the last value for everything). Passing it as an argument sidesteps that entirely, and is still good practice to know even on newer Go versions where the loop variable semantics changed.

Channels: Goroutines Talking to Each Other

WaitGroups tell you when things are done. Channels let goroutines actually communicate — passing data between them safely, without manual locks:

func main() {
    results := make(chan string, 3)

    go fetchAndSend("orders", results)
    go fetchAndSend("payments", results)
    go fetchAndSend("inventory", results)

    for i := 0; i < 3; i++ {
        fmt.Println(<-results)
    }
    close(results)
}

func fetchAndSend(name string, results chan<- string) {
    time.Sleep(100 * time.Millisecond)
    results <- fmt.Sprintf("%s: 200 OK", name)
}

A channel is a typed pipe. results <- value sends, <-results receives, and both block until someone's on the other end (unless the channel is buffered, like the make(chan string, 3) above, which allows up to 3 sends before blocking). The chan<- string parameter type is a send-only channel — a nice bit of compiler-enforced documentation saying "this function only writes here, it never reads."

This is the part that reframes concurrency entirely coming from Java. The Go proverb is "don't communicate by sharing memory, share memory by communicating" — instead of multiple threads fighting over a synchronized block or a ConcurrentHashMap, you pass ownership of data through a channel, one direction at a time. There's no lock to forget, because there's nothing shared to protect.

select: Handling Multiple Channels at Once

Once you have more than one channel, select lets you react to whichever one is ready first — it's the concurrency equivalent of a switch statement:

func main() {
    payments := make(chan string)
    timeout := time.After(2 * time.Second)

    go processPayment(payments)

    select {
    case result := <-payments:
        fmt.Println("payment result:", result)
    case <-timeout:
        fmt.Println("payment timed out")
    }
}

func processPayment(payments chan<- string) {
    time.Sleep(3 * time.Second) // simulate a slow downstream call
    payments <- "success"
}

This pattern — racing a real channel against time.After — is how Go handles timeouts idiomatically. No Future.get(timeout, unit) with a checked TimeoutException to catch. Just two channels and a select.

Where This Actually Bites You

I don't want to oversell this as friction-free, because it isn't. A few things I've already tripped over:

Goroutine leaks are real and easy to cause. If a goroutine is blocked sending on a channel that nobody's ever going to read from again, it just sits there forever, leaking memory. Unlike a thread pool with bounded size, there's no natural backpressure unless you design it in yourself — usually with buffered channels, context.Context cancellation, or both.

Deadlocks look different than JVM deadlocks. Instead of two threads each holding a lock the other wants, a Go deadlock is more often "every goroutine is blocked waiting on a channel, and nothing's left to unblock them." The runtime is actually good at detecting this for the simplest cases (fatal error: all goroutines are asleep - deadlock!), which is more help than the JVM ever gave me.

Unbuffered channels make ordering subtle. An unbuffered channel send blocks until a receiver is ready, which means the timing of goroutines relative to each other isn't always obvious from reading the code top to bottom. It took a few go run experiments with print statements before the mental model clicked.

go vet and the race detector are not optional. Running go run -race during development catches data races that would otherwise be silent and only show up under load in production. I now run it by default the way I'd run a linter.

Why This Matters for the Series

This concurrency model is going to show up constantly once I build a real API in part 5 — handling concurrent requests, fanning out to multiple downstream services, and managing timeouts cleanly are exactly what channels and select are built for. It's also a big part of why Go shows up so often in infra and backend tooling: the concurrency primitives are cheap enough that you reach for them by default, not just when you've hit a performance wall.

Next up in part 4: error handling. I promised in part 1 that if err != nil would get its own post, and after spending real time with goroutines that return errors over channels, I have a lot more sympathy for Go's approach than I expected to.

If you've worked with both JVM threads and goroutines, I'd like to know — did the "share memory by communicating" mental shift come naturally, or did you find yourself reaching for locks out of habit at first?