Goroutines, Channels & Select

Overview

go starts a goroutine now. It is not an OS thread, and it is not a lazy future. Channels hand off ownership by convention (the sender stops touching the value). select waits until a case can proceed and picks pseudo-randomly among ready cases (only loosely like Promise.race). Reach for sync.Mutex, sync.WaitGroup, or an atomic when you are not handing off a value.

flowchart TB
  A["Step 1 go f() starts a goroutine Ready"]
  B["Step 2 It sends results on a channel Ready"]
  C["Step 3 select waits until a case is ready Ready"]
  D["Step 4 Which case is ready Ready"]
  E["Step 5a Handle the value Ready"]
  F["Step 5b Stop and return Ready"]
  G["Step 6 The sole sender closes the channel when done Ready"]
  H["Step 7 range over the channel ends after the buffer drains Ready"]
  X["Failure path - goroutine leak, blocked forever Ready"]
  A -->|continues| B
  B -->|continues| C
  C -->|continues| D
  D -->|value| E
  D -->|ctx.Done or timer| F
  E -->|continues| G
  G -->|continues| H
  B -->|nobody ever receives| X

Press Run. Snippets must be self-contained — no network, files, or native modules.

The sketch records that the work ran and was joined. A Go WaitGroup is that join without a message.

Rosetta — start and wait

package conc

import (
    "fmt"
    "sync"
)

func Demo() {
    var wg sync.WaitGroup
    wg.Add(1)
    go func() {
        defer wg.Done()
        fmt.Println("runs concurrently")
    }()
    wg.Wait()
}

async function demo() {
  const p = Promise.resolve().then(() => console.log("microtask"));
  await p;
}

import threading

def demo() -> None:
    thread = threading.Thread(target=lambda: print("runs concurrently"))
    thread.start()
    thread.join()

Goroutines are multiplexed. A TypeScript async function still rides one thread unless you start workers. A Python thread is an OS thread that shares objects under the GIL. asyncio is cooperative on one thread.

Rosetta — channel and select

package chans

import "time"

func Demo() string {
    ch := make(chan string, 1)
    ch <- "hi"
    select {
    case v := <-ch:
        return v
    case <-time.After(time.Second):
        return "timeout"
    }
}

async function demo(signal: AbortSignal): Promise<string> {
  const value = Promise.resolve("hi");
  const timeout = new Promise<string>((_, reject) => {
    const timer = setTimeout(() => reject(new Error("timeout")), 1000);
    signal.addEventListener("abort", () => clearTimeout(timer));
  });
  return Promise.race([value, timeout]);
}

import asyncio

async def demo() -> str:
    task = asyncio.create_task(asyncio.sleep(0, result="hi"))
    try:
        return await asyncio.wait_for(task, timeout=1.0)
    except TimeoutError:
        return "timeout"

A buffer of 1 lets the send finish before the receive. An unbuffered send waits for a receiver. select waits until a case can proceed and picks pseudo-randomly among ready cases (only loosely like Promise.race). asyncio.wait_for is the shape of a timeout, not the scheduler.

When not to use a channel

The sender closes - the only one, or a coordinator after all senders finish; never the receiver. A send after close panics. A receive drains buffered values first, then yields the zero value with ok == false. Do not close from the receiver.

Interview Q&A

Pitfalls

• go with no wait and no cancellation.
• Closing from the receiver.
• A channel that only protects a counter.
• A map write from two goroutines.

Go Deeper

• Concurrency is not parallelism
• Share memory by communicating