Go

Understand

Go was designed for fast compilation and simple concurrency at Google's scale. These are the technical decisions that make it fast.

3 numbers that matter

Why Go compiles so fast

Compilation time comparison

Why Go is "fast enough"

Go isn't the fastest language at raw computation. It's 30-200% slower than Rust/C++ in CPU-intensive tasks. But it's fast enough for:

• 95% of server workloads: networked services, APIs, microservices
• Cloud-native applications: fast startup, small binaries, easy containerization
• DevOps tooling: Docker, Kubernetes, Terraform, Prometheus all written in Go

Maturity map

Terms & Glossary

Hover over highlighted termsTerm TooltipThroughout this page, terms with dotted underlines show definitions when hovered. anywhere on this page for definitions.

Decide

When to use Go vs alternatives.

Runtime Deep Dive

GMP Scheduler Model

Go's scheduler multiplexes millions of goroutines onto a small pool of OS threads.

Scheduling flow

Garbage Collector

Go uses a concurrent tri-color mark-and-sweepTri-Color GCObjects classified as White (unvisited), Gray (reachable, children not scanned), Black (fully scanned). White objects collected. collector optimized for low latency.

GC evolution

GC tuning

Why goroutines are cheap

With 2KB stacks: 0.5 million goroutines per GB of RAM.

Concurrency That Composes

Coming from the async world, the instinct is to build composable futures — a pending value you chain: f.Map(...).Then(...).Recover(...). In Go that instinct fights the language. The idiomatic answer is not a better futures library. It is not building one.

Why futures don't compose in Go

Two language decisions kill the promise-algebra approach before it starts:

// compile error: a method can't add type params
func (f *Future[T]) Map[U any](fn func(T) U) *Future[U]

// no Result[T, error]. errors are a second return.
func fetch(ctx context.Context, url string) ([]byte, error)

Structured concurrency: hide it behind (T, error)

The Go move is to spin up goroutines, wait for them, and return a plain (T, error). The concurrency becomes an implementation detail behind an ordinary synchronous signature — and that composes, because it is just function composition with a context.Context threaded through. This is structured concurrencyStructured concurrencyChild task lifetimes nest like lexical scopes: a function that spawns goroutines waits for all of them before returning, so control flow stays a tree, not an escaped go statement.: child lifetimes nest like scopes, so control flow stays a tree instead of an escaped go[23].

Fan-out / collect: errgroup

The canonical form uses golang.org/x/sync/errgroup:

func FetchAll(ctx context.Context, urls []string) ([]Result, error) {
    g, ctx := errgroup.WithContext(ctx)
    results := make([]Result, len(urls))
    for i, url := range urls {
        g.Go(func() error {
            r, err := fetch(ctx, url)   // ctx cancels the instant any sibling errors
            if err != nil {
                return err
            }
            results[i] = r              // distinct index per goroutine, no lock
            return nil
        })
    }
    if err := g.Wait(); err != nil {    // returns the first non-nil error
        return nil, err
    }
    return results, nil
}

FetchAll composes because it is a normal function returning (T, error). The caller does the same trick one level up; cancellation propagates down the ctx chain automatically. g.SetLimit(n) bounds concurrency when you need a worker pool. This is the idiom that replaced "build a futures library."

Streaming: the pipeline pattern

When you actually want a → b → c stages, channels genuinely compose. Each stage is func(ctx, <-chan In) <-chan Out, owns its output channel, and closes it with defer:

func sq(ctx context.Context, in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)               // close ONLY the channel you created
        for n := range in {            // drain upstream until it closes
            select {
            case out <- n * n:
            case <-ctx.Done():          // guard every send: consumer may walk away
                return
            }
        }
    }()
    return out
}

// composes cleanly, inside-out:
for n := range sq(ctx, sq(ctx, gen(ctx, 2, 3))) {
    fmt.Println(n)
}

The "no harakiri" rules are mechanical: each stage closes only the channel it created, downstream for range drains until that close, and every send is guarded by a select on ctx.Done() so nothing blocks forever when a consumer leaves. Cancellation collapses the whole pipeline. This is the Go blog's "Pipelines and cancellation" model[25] — the original used a hand-rolled done channel; ctx.Done() is the modern drop-in.

When it really is a DAG

If a problem genuinely is a DAG of dependent async results — C needs A and B, A and B run in parallel — github.com/sourcegraph/conc ("better structured concurrency for go") offers WaitGroup, typed pools, and iter.Map[26]. But most Go that reaches for it reads more naturally as nested errgroup calls. (Popular at ~10k stars, but effectively stale — last release v0.3.0, 2023.)

Why this beats the async world

Promises and async/await exist because the async world needs a composition primitive: a colored function can't just block, so it returns a future and you chain on it. Go deletes the premise. Because the scheduler parks a blocked goroutine for ~2KB of stack and runs another, blocking is cheap — so a synchronous signature can hide arbitrary concurrency, and ordinary function composition is enough. No colors to propagate, no future to thread, no Result to unwrap.

Channels: Cost & Coordination

Channels compose — the pipeline proves it — but they are not free, and they are more than a queue. Two things worth knowing before you reach for one: what a channel operation costs, and how a channel broadcasts.

What a channel costs

A channel send is not "slow" in absolute terms — it is slow relative to what it does. Internally a send is a mutex acquisition + a copy of the element + possibly a goroutine park and wakeup. The ladder, uncontended, modern x86, order of magnitude:

When the cost matters

For a pipeline stage that does a few microseconds of real work per value, ~100 ns of channel overhead is noise — the same logic as a 15 ns interface call against 1–100 ms of network latency. It bites in a hot inner loop shuttling millions of tiny values between goroutines: there a channel-per-item can dominate the wall clock. The fixes are mechanical — batch (send slices, not ints), or guard a shared structure with a mutex. Don't reach for a channel to protect one counter; reach for it when work or ownership flows.[27]

Broadcasting: one signal, N goroutines

The thing a channel does that a plain queue cannot: broadcast. A send reaches exactly one receiver; closing a channel wakes every goroutine blocked on it at once, and every future receive returns immediately. That asymmetry is the whole trick — and it is exactly how ctx.Done() fans cancellation out to a whole tree.

// close = broadcast. one close, N wakeups, no value sent.
done := make(chan struct{})
for i := 0; i < n; i++ {
    go func() {
        select {
        case w := <-work:
            handle(w)
        case <-done:          // all N goroutines wake when done closes
            return
        }
    }()
}
close(done)                  // signal everyone at once

A closed channel is a latch, not a message: it stays closed, and every receiver sees it. That is why close — not send — is the broadcast primitive, and why context cancellation is just a closed Done() channel underneath.[29]

Close is also a memory barrier

Closing a channel does more than wake receivers — it establishes memory ordering. The Go memory model, verbatim: "The closing of a channel is synchronized before a receive that returns a zero value because the channel is closed."[30] ("synchronized before" is the modern term; older docs say "happens before".) So a producer can write a plain field, then close; the consumer receives the close, then reads that field — with no lock around it and no data race.

type result struct {
    val Data
    err error
}

func compute() (*result, <-chan struct{}) {
    r := &result{}
    done := make(chan struct{})
    go func() {
        r.val, r.err = expensive()  // plain writes, no lock
        close(done)                 // close = release barrier
    }()
    return r, done
}

// consumer:
r, done := compute()
<-done                              // receiving the close = acquire barrier
use(r.val, r.err)                   // race-free read, still no lock

The chain is mechanical: the producer writes the field then closes (ordered within one goroutine); the close is synchronized-before the receive returning (the memory model rule); the receive is before the consumer's read (ordered within the other goroutine). Transitively the write is synchronized-before the read — not a race — even though the value never travelled through the channel. It holds under one discipline: the fields are written before the close, nothing writes them after, and readers touch them only after the receive. You signal through the channel and ship the value beside it: the close carries the ordering, the field carries the data. This is the bones of sync.Once and of any "compute once, read many" value.

Pick the right signal

Type System & Interface Dispatch

Go's type system is simple to use but has heavy runtime machinery underneath. Understanding it explains both why Go works and where it costs you, vs Rust and TypeScript.

Hybrid typing: structural + nominal

type Celsius float64
type Fahrenheit float64
// Cannot assign Celsius to Fahrenheit
// Must explicitly convert

type Reader interface {
    Read(p []byte) (n int, err error)
}
// *os.File satisfies Reader
// No "implements" keyword needed

Runtime type representation

Every type has an abi.Type descriptor in the binary (from internal/abi/type.go):

Key flag: TFlagDirectIface — when set, concrete value stored directly in interface (not pointer to heap). Used for pointers and single-word values.

Interface memory layout

Interfaces are fat pointers — 16 bytes on 64-bit systems:

Empty interfaces (any/interface{}) skip the itab lookup since there are no methods to dispatch.

The itab: Go's virtual table

The itabInterface TableCore dispatch structure containing interface type, concrete type, and method function pointers. Cached globally for reuse. (interface table) is Go's mechanism for dynamic dispatch:

type itab struct {
    inter *interfacetype  // Interface being satisfied
    _type *_type          // Concrete type implementing it
    hash  uint32          // Copy of _type.hash (fast type switches)
    _     [4]byte         // Padding
    fun   [1]uintptr      // Variable-sized method table (vtable)
}

How Go decides which method to call

Assembly view of interface call

MOVQ    (r.tab), DX        // Load itab pointer
MOVQ    24(DX), AX         // Load fun[0] (method at offset 24)
MOVQ    8(r), CX           // Load r.data (concrete value)
CALL    AX                 // Jump to method

Offset 24 = sizeof(inter) + sizeof(_type) + sizeof(hash) + padding = 8+8+4+4.

Method set rules

type Stringer interface { String() string }

type S struct{}
func (s *S) String() string { return "S" }

var _ Stringer = &S{}   // OK: *S has String
var _ Stringer = S{}    // ERROR: S doesn't have String

Compiler optimizations

Devirtualization

When the compiler can prove the concrete type, it converts interface calls to direct calls:

h := sha1.New()      // Returns hash.Hash, but compiler knows it's *sha1.digest
h.Write(data)        // Converted to direct call: sha1.(*digest).Write

Check with: go build -gcflags='-m'

Profile-Guided Optimization (Go 1.21+)

PGO transforms hot interface calls based on runtime profile data:

// Before PGO
r.Read(buf)

// After PGO (if profile shows *os.File dominates)
if f, ok := r.(*os.File); ok {
    f.Read(buf)      // Direct call, inlinable
} else {
    r.Read(buf)      // Fallback indirect call
}

Result: 2-14% CPU reduction typical.

Performance cost breakdown

Common pitfalls

1. The nil interface trap

func maybeError() error {
    var p *os.PathError = nil
    return p  // Returns (type=*os.PathError, data=nil)
}

err := maybeError()
fmt.Println(err == nil)  // false! Interface has type but nil data

An interface is nil only when both tab (or _type) AND data are nil.

func maybeError() error {
    var p *os.PathError = nil
    if p == nil {
        return nil  // Returns (type=nil, data=nil)
    }
    return p
}

2. Escape analysis failure

func process(r io.Reader) {
    buf := make([]byte, 1024)  // Escapes to heap!
    r.Read(buf)                // Compiler can't analyze through interface
}

Compiler doesn't know concrete Read implementation → assumes buffer could be retained → heap allocation.

3. Type assertion panics

m := map[string]any{"count": 42}
count := m["count"].(int64)  // PANIC: 42 is int, not int64

// JSON unmarshaling is worse:
var data map[string]any
json.Unmarshal([]byte(`{"count":42}`), &data)
count := data["count"].(int)  // PANIC: it's float64!

Fix: Use comma-ok form or type switch.

Comparison: Go vs Rust vs TypeScript

Rust's approach

// Static dispatch (monomorphization) - zero cost
fn process<R: Read>(r: R) { ... }

// Dynamic dispatch (vtable) - explicit opt-in
fn process(r: &dyn Read) { ... }

Rust advantage: You choose. Default is zero-cost. dyn vtable is ~3 ns (smaller than Go's itab).
Rust disadvantage: Monomorphization causes binary bloat and longer compile times.

TypeScript's approach

interface Reader {
    read(buf: Uint8Array): number;
}
// Types completely erased at runtime
// API response typed as User is actually `any`

TypeScript problem: No runtime type checking. I/O boundaries are unsafe. Need Zod or similar for validation.

Why Go's tradeoff works

Generics: Go's partial monomorphization

Go 1.18+ generics use GCShape stenciling with dictionaries — a hybrid approach:

Go vs Rust

Different philosophies: Go prioritizes developer velocity, Rust prioritizes correctness.

Compilation speed

Runtime performance

Rust's dynamic dispatch deep dive

To understand why Go and Rust make different tradeoffs, we need to see how Rust handles dynamic dispatch and how it interacts with async.

Rust vtable vs Go itab

// Interface always uses itab
var r io.Reader = file
r.Read(buf)  // vtable lookup

// Static dispatch (default)
fn process<R: Read>(r: R) { }

// Dynamic dispatch (explicit)
fn process(r: &dyn Read) { }

Rust vtable structure

Rust's vtable layout is simpler than Go's itab:

// Rust vtable layout (conceptual)
struct Vtable {
    drop_in_place: fn(*mut ()),     // Destructor
    size: usize,                     // sizeof(T)
    align: usize,                    // alignof(T)
    method_0: fn(*const ()) -> R,   // First trait method
    method_1: fn(*const ()) -> R,   // Second trait method...
}

Key differences:

• No runtime construction: Rust vtables are compiled into the binary, no getitab() equivalent
• No hash table: Direct pointer to static vtable, no global cache
• Destructor included: drop_in_place enables Box<dyn Trait> to clean up

Dispatch performance comparison

Real-world benchmark: 20M element iteration

*Estimated based on similar workloads; actual varies by GC pressure and escape analysis.

The three dispatch tiers

When each matters

The colored functions problem

The deepest architectural difference between Go and Rust concurrency is "function colors."

// All functions are the same "color"
func process(items []int) {
    for _, item := range items {
        go handleItem(item)  // Just spawn
    }
}

func handleItem(x int) {
    // Can do I/O, blocking, anything
    time.Sleep(time.Second)
    fmt.Println(x)
}

// Async functions are "colored"
async fn process(items: Vec<i32>) {
    for item in items {
        handle_item(item).await;  // Must await
    }
}

async fn handle_item(x: i32) {
    tokio::time::sleep(Duration::from_secs(1)).await;
    println!("{}", x);
}

Why colors matter

// Rust: Can't do this!
fn sync_function() {
    // ERROR: `await` is only allowed inside `async` functions
    async_database_query().await;
}

// Must propagate async up the call stack
async fn sync_function() {        // Now async
    async_database_query().await;
}

// Or use block_on (spawns new runtime, expensive)
fn sync_function() {
    tokio::runtime::Runtime::new()
        .unwrap()
        .block_on(async_database_query());
}

Go avoids this entirely: The scheduler handles blocking transparently. When a goroutine blocks on I/O, the runtime parks it and runs another — no code changes needed.

Async traits: Rust's ongoing challenge

Combining async with dyn Trait has been one of Rust's hardest problems.

The problem

// This doesn't work directly
trait Database {
    async fn query(&self) -> Vec<Row>;  // Returns impl Future, size unknown!
}

// Can't put in vtable: Future size varies per implementation

Why? Async functions return impl Future — the concrete Future type differs per implementation. Vtables need fixed-size entries.

Solution 1: async_trait crate (pre-1.75)

#[async_trait]
trait Database {
    async fn query(&self) -> Vec<Row>;
}

// Expands to:
trait Database {
    fn query(&self) -> Pin<Box<dyn Future<Output = Vec<Row>> + Send>>;
}

Cost: Every call allocates a Box on the heap. ~10-50 ns overhead per call.

Solution 2: Return-Position Impl Trait in Traits (Rust 1.75+)

// Now works natively! (Rust 1.75, Dec 2023)
trait Database {
    fn query(&self) -> impl Future<Output = Vec<Row>>;
}

// But: still can't use with dyn Database easily
// Need trait_variant or manual boxing for dynamic dispatch

Still evolving: async fn in traits landed, but dyn Trait with async methods requires trait_variant or explicit boxing.

Async dispatch performance

Send + Sync: Rust's async complexity tax

Rust async functions capture their environment. Moving Futures across threads requires proving thread safety.

// This fails:
async fn process(data: &RefCell<Data>) {
    // RefCell is not Sync, can't hold across .await
    let guard = data.borrow();
    async_operation().await;  // ERROR: future is not Send
    println!("{:?}", guard);
}

// Go equivalent just works:
func process(data *Data) {
    mu.Lock()
    defer mu.Unlock()
    asyncOperation()  // Blocks, but goroutine handles it
    fmt.Printf("%v\n", data)
}

Rust forces you to think about:

• What data is held across .await points
• Whether the Future can be Send (movable between threads)
• Whether shared state is Sync (accessible from multiple threads)

Go hides this: The runtime manages goroutine migration. Data races are possible but not compile errors.

What Rust could borrow from Go

Philosophical differences

When to use each

2025 trend: Hybrid stacks are common. Go for services, Rust for performance-critical components.

Go vs TypeScript

Compiled native code vs JIT-compiled JavaScript.

Execution model

Performance benchmarks

Type system differences

Concurrency models

Real-world migrations

When to choose

Building UIs — Go vs Rust vs C++

Go's UI story is shaped by the language's design. Go is a GC'd, runtime-heavy, backend-first language with no zero-cost abstractions and thin GPU/FFI. So it wins where concurrency, HTTP, and a single static binary matter, and trails where you need zero-cost GPU access, a tiny WASM payload, or bare metal. Below: what's good and why, then the gaps versus Rust and C++ and why they exist.

What's good — and why

The gaps vs Rust / C++ — and why

Six places Go trails the frontier, each traced to a design choice.

The full field

Learn

Key resources

Popular frameworks