Languages

TL;DR

A language is the sum of four choices: type system, runtime model, memory model, concurrency model. Mastering a language is mastering its position on each axis. Learning the next language is reading the delta. Syntax is the last thing that transfers; the axes are the first. This roadmap names the axes, places real languages on them, and suggests the order to visit.

You will be able to

• Place any language on the four axes in under a minute.
• Predict the debugging flavor of a language before you write a line of it.
• Choose your next language by the axis you haven't yet stretched.

The Map

• You will be able to
• The Map
• Station 1 — Type systems
• Station 2 — Runtime models
• Station 3 — Memory models
• Station 4 — Concurrency primitives
• Station 5 — Evaluation and dispatch
• Station 6 — The polyglot's ordering
• How the stations connect
• Standards & Specs
• Test yourself

Four axes, four or five options each. ~1000 combinations; perhaps 30 that anyone uses. A language is a point in this space, and its personality — how it debugs, how it scales, how it crashes — is the product of its coordinates.

Station 1 — Type systems

The type system answers two questions: when are types checked (static vs dynamic), and how strictly (strong vs weak). Two more questions refine the picture: by name (nominal) or by shape (structural)? And how much does the compiler figure out on its own (inference)?

                           ┌────────────────────────────────────┐
                           │              STATIC                │
                           │  ┌──────────┐      ┌──────────┐    │
                           │  │  Java    │      │  Rust    │    │
                 STRONG    │  │  nominal │      │ nominal+ │    │
                           │  └──────────┘      └──────────┘    │
                           │        ┌──────────────┐            │
                           │        │  TypeScript  │            │
                           │        │  structural  │            │
                           │        └──────────────┘            │
                           ├────────────────────────────────────┤
                           │             DYNAMIC                │
                           │  ┌──────────┐      ┌──────────┐    │
                           │  │  Python  │      │  Ruby    │    │
                           │  │          │      │          │    │
                           │  └──────────┘      └──────────┘    │
                           │  ┌──────────┐      ┌──────────┐    │
                  WEAK     │  │   C      │      │JavaScript│    │
                           │  │          │      │          │    │
                           │  └──────────┘      └──────────┘    │
                           └────────────────────────────────────┘

The model you want: static types move errors from runtime to compile time, at the cost of expressiveness. Strong types refuse to coerce; weak types coerce and hope. Inference decides how much of the type system you have to type yourself. Structural typing is duck typing that the compiler can check.

Go deeper: Benjamin Pierce's Types and Programming Languages chapters 1–9 (skim, then return when you meet Rust or Haskell); write the same non-trivial program in one static and one dynamic language and count the bugs each caught.

Station 2 — Runtime models

How does source text become running instructions? Four routes:

• AOT compiled — everything resolved before the program runs. Fast start, predictable performance, hard to hot-patch.
• Interpreted — source walked at run time. Slow, but trivial to ship and modify.
• Bytecode + VM — source compiled to an intermediate form; VM executes it. Portable, moderate speed.
• JIT — VM watches hot paths and compiles them to machine code at run time. Slow to warm up, near-AOT speed at peak. Crucially, can deoptimize if assumptions break.

The model you want: startup vs peak performance is a choice. AOT wins the start, JIT wins the peak, interpretation wins time-to-ship. Serverless loves AOT; long-running servers love JIT.

Go deeper: Mike Pall's LuaJIT writeups; Cliff Click's "A crash course in modern hardware" for why JITs exist; read the Go compiler's README — the whole toolchain fits in a morning.

Station 3 — Memory models

Who frees the memory?

  Manual        Refcount         Tracing GC        Ownership
  ───────       ─────────        ───────────       ──────────
  You do.       Every ref        Runs periodically  Compiler tracks
  You leak.     bumps a count.   over the heap.     who owns what.
  You UAF.      Cycles leak      Stops the world    Enforces at
                without help.    (sometimes).       compile time.

  C, C++ raw    Swift, Python    Java, Go, C#       Rust
                CPython           JS, Ruby

Four strategies. Each trades correctness, performance, and cognitive load differently:

• Manual — you call free. Fastest, most unforgiving. Use-after-free and double-free are your pets.
• Reference counting — every reference is a counter increment; drop to zero frees. Predictable, but leaks cycles unless you add weak references or a cycle collector.
• Tracing GC — periodically walk live references from roots; collect the unreachable. Pauses are the cost. Generational GCs make the common case (young objects dying fast) cheap.
• Ownership / borrowing — compiler tracks a single owner per value and which references borrow for how long. No leaks, no use-after-free, no runtime cost. Steep learning curve.

The model you want: memory safety is unavoidable engineering work; the only question is where the work happens. Manual puts it in your head. Refcount puts it in the runtime and leaks cycles. GC puts it in the runtime and pauses. Ownership puts it in the compiler and frustrates you until you think in lifetimes.

Go deeper: Chapter 4 of The Rust Book (ownership) even if you never ship Rust; Richard Jones's The Garbage Collection Handbook for the serious version; instrument one JVM service with -XX:+PrintGCDetails for a week.

Station 4 — Concurrency primitives

Four dominant models:

• OS threads + locks — kernel schedules; you coordinate with mutexes, semaphores, condition variables. The classic, most general, easiest to get wrong.
• Green threads — many user-space threads multiplexed onto a few OS threads. Cheap to create (millions). Go's goroutines, Java 21's virtual threads.
• Async / await — single-threaded cooperative multitasking on an event loop. Non-blocking I/O is free; CPU work blocks everyone.
• Actors / CSP — no shared state; message passing between isolated units. Scales horizontally without locking.

The model you want: the concurrency primitive is the shape of every bug you'll write in the language. OS threads give you races. Green threads give you cheap concurrency but still shared-state bugs. async/await gives you event-loop-hogging bugs. Actors give you mailbox-overflow and ordering bugs.

Go deeper: Rob Pike's "Concurrency is not Parallelism" talk; Java Virtual Threads (JEP 444) even if you don't use Java; Elixir in Action Chapter 5 for actors done clearly.

Station 5 — Evaluation and dispatch

Small axis, large consequences. When expressions evaluate, and how calls dispatch, change what a language feels like day to day.

  Evaluation:
    strict  → arguments evaluated before the call                   (most languages)
    lazy    → arguments evaluated only when needed                  (Haskell, some Scala)

  Dispatch:
    static  → compile-time, by declared type                        (C function calls)
    dynamic → runtime, by object type                               (Java virtual methods)
    multi   → by types of all arguments                             (Julia, CLOS, Dylan)

  Polymorphism flavors:
    parametric → generics ("works for any T")                       (Java <T>, Rust <T>)
    ad-hoc     → overloading ("works for these T")                  (Rust traits, Haskell classes)
    subtype    → inheritance ("works for any subclass")             (Java, C#, C++)

The model you want: every language picks a default and charges extra for the others. Java's default dispatch is virtual (dynamic); final opts out. Haskell's default is lazy; seq opts in. Knowing the defaults tells you what's cheap and what's expensive to express.

Go deeper: Structure and Interpretation of Computer Programs ch. 3 (lazy evaluation); On Lisp ch. 25 (multi-dispatch); one afternoon writing the same code with and without generics in a language you know.

Station 6 — The polyglot's ordering

You get diminishing returns from your fourth Java-family language. You get compounding returns from one language in each major family. A recommended order, if starting fresh:

The logic: each step stretches an axis you haven't touched. Python → Go adds static types and green threads. Go → Java adds JIT and OS-thread-and-lock concurrency. Java → Rust adds ownership and replaces GC. Rust → Haskell stretches evaluation and purity.

The model you want: the next language that teaches you the most is the one furthest on the axis you've never moved. Learning "one more mainstream language" is a rounding error.

Go deeper: Seven Languages in Seven Weeks (dated but the premise stands); a three-month deliberate polyglot project in the language that covers an axis you don't know.

How the stations connect

The four axes are orthogonal in theory but correlated in practice. Static + tracing GC + OS threads is the JVM corner. Static + ownership + async is the Rust corner. Dynamic + GC + event loop is the JS/Python corner. When a corner gets popular, a cluster of tools grows around it, and the axis choices propagate through the ecosystem.

Read: the personality of a language — how it debugs, how it scales, how it crashes — is predictable from the coordinates, not from the syntax.

Standards & Specs

The authoritative references that govern programming languages. Many languages are defined by an ISO or ECMA specification; the canonical papers below are what the spec editors actually read.

• ISO/IEC 9899 — C — the C standard (C23 current).
• ISO/IEC 14882 — C++ — the C++ standard (C++23 current).
• ECMA-262 — ECMAScript — the JavaScript language specification, updated yearly by TC39.
• ISO/IEC 10646 — Unicode Universal Character Set and the Unicode Standard — what every modern string type is secretly about.
• IEEE 754 — floating-point arithmetic; the thing that is the same across every language that says it has "numbers."
• POSIX — IEEE 1003.1 — the OS contract every runtime has to negotiate with.
• The Rust Reference — the current closest thing to a Rust spec; the ownership and borrow rules live here.
• The Go Programming Language Specification — Go's one-document, read-in-an-afternoon spec.
• The Java Language Specification and JVM Specification — separated on purpose; worth reading both.
• Papers — Pierce, Types and Programming Languages; Milner, "A Theory of Type Polymorphism in Programming" (1978); Jones, The Garbage Collection Handbook; Hoare, "Communicating Sequential Processes" (CACM 1978).

Test yourself