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.

Type System & Interface Dispatch

Go's type system is deceptively simple on the surface but has sophisticated runtime machinery underneath. Understanding it explains both Go's power and its tradeoffs 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

Learn

Key resources

Popular frameworks