3.9 — A Comparative Tour: C, Python, Java, Go, Rust

Chapters 3.1–3.8 built the theory of languages and then went deep on one stack. This chapter does the opposite: a comparative tour of five languages that between them cover the whole design space you've been learning. The purpose is not to make you fluent in each — it's that every language embodies a set of answers to the questions of this Part, and seeing the same questions answered five different ways is what turns abstract knowledge into judgment.

For each language, the same lens: what problem it was created to solve, its answers on translation (3.2), types (3.3), memory (3.4), and concurrency (2.3/2.4) — and, most usefully, what it teaches you that other languages don't.

1. C — the machine's language

Created: 1972, Dennis Ritchie at Bell Labs, to write the Unix kernel (2.1) in something better than assembly while staying close enough to the hardware to be efficient. That origin explains everything about it.

Its answers: AOT compiled straight to native machine code; static but weak typing (3.3 — you can freely reinterpret memory via pointer casts, and it will oblige); manual memory management (malloc/free) with all the hazards of 3.4; concurrency via raw OS threads and locks.

What it teaches. C is a thin, honest layer over the machine of Part 1 — there is very little between a line of C and the instructions it becomes. Writing it forces you to confront pointers as memory addresses, the stack/heap distinction (3.4), manual lifetimes, and exactly how much a higher-level language is doing for you. If you've only used managed languages, a week of C makes concepts like reference vs value, buffer, and undefined behaviour concrete rather than theoretical.

Where it still lives: operating-system kernels, embedded systems and firmware, device drivers, and the implementation of nearly everything else (CPython, V8, Node's libuv, most database engines, and the C standard library are all C or C++). Its enduring role is as the substrate — the language other languages are written in.

Its cost, stated plainly: the memory-safety burden of 3.4 — roughly 70% of serious security vulnerabilities at major vendors are memory-safety errors — plus undefined behaviour, where a program that breaks the rules (signed overflow, reading uninitialised memory, an out-of-bounds index) may do anything, including appearing to work until it catastrophically doesn't.

2. Python — optimised for the programmer

Created: 1991, Guido van Rossum, explicitly prioritising readability and developer productivity over machine efficiency. Its design philosophy ("there should be one obvious way to do it," significant indentation forcing readable structure) is unusually explicit.

Its answers: compiled to bytecode and interpreted by the CPython VM (3.2 — the __pycache__/.pyc files are its cached bytecode); dynamic but strong typing (3.3 — "5" + 3 is an error, unlike JavaScript), with optional type hints checked by external tools like mypy (gradual typing); memory via reference counting plus a cycle collector (3.4).

What it teaches. That developer time is often the scarcer resource. Python's ascendancy in data science, machine learning, scripting, and automation is a demonstration that expressiveness and ecosystem frequently beat raw speed — and its architecture shows how: performance-critical work is delegated to AOT-compiled native libraries (NumPy, PyTorch, and most of the scientific stack are C/C++/Fortran under a Python skin), so Python is the orchestration layer, not the compute layer. That "fast glue over fast kernels" pattern is a genuinely important architectural idea.

Its notorious constraint — the GIL. CPython has a Global Interpreter Lock: a single mutex (2.4) ensuring only one thread executes Python bytecode at a time. It exists largely because reference counting (3.4) requires every count update to be atomic, which would be ruinously expensive per-operation without a coarse global lock. The consequence: Python threads give you concurrency but not parallelism for CPU-bound Python code (2.3) — adding threads to a CPU-bound Python program yields no speedup. Threads do help for I/O-bound work (the GIL is released while waiting), and true parallelism comes from multiprocessing (separate processes, separate GILs — 2.2) or native libraries that release the GIL. (Recent versions have begun offering an optional free-threaded build removing the GIL — a long-running effort precisely because reference counting makes it hard.)

3. Java — engineering for large teams

Created: 1995, James Gosling at Sun, targeting portability ("write once, run anywhere") and safety compared to C++, for large enterprise systems built by large teams.

Its answers: compiled to bytecode run by the JVM with a sophisticated tiered JIT (3.2 — C1 and C2 compilers, plus warmup); static and strong typing, nominal (3.3) with generics; tracing garbage collection (3.4) with a choice of world-class collectors (G1, and the low-pause ZGC/Shenandoah); OS-thread concurrency with a mature memory model, and now lightweight virtual threads.

What it teaches. How languages and runtimes scale to organisations, not just to machines. Java's verbosity, explicit types, and strong conventions are a deliberate optimisation for code being read and modified by many engineers over many years — the 3.3 point that static typing's real payoff is refactoring confidence, taken to its conclusion. Its JVM is also arguably the best-engineered managed runtime in existence: the JIT and collectors described abstractly in 3.2 and 3.4 are, in the JVM, the products of thirty years of tuning — which is why a warmed-up Java service can approach native performance.

A few concrete Java behaviours worth knowing (they appear in interviews and reveal design choices): the String pool interns string literals so identical literals share one object (saving memory, and the reason == on strings compares references and misleads — always use .equals()); the Integer cache pre-allocates boxed Integer objects for −128…127, so Integer.valueOf(100) == Integer.valueOf(100) is true while the same comparison at 1000 is false (a classic trap that exists to reduce allocation for common small values); and class file versions record which JDK compiled a class, producing UnsupportedClassVersionError when a newer-compiled class runs on an older JVM. ^{⚑0–127 value caching in Java; what is the String pool? [EQ-144]⚑What is Java class version — difference, significance, correlation? [EQ-66b]}

4. Go — simplicity as the feature

Created: 2009 at Google (Rob Pike, Ken Thompson — Thompson also co-created Unix and C's ancestor), explicitly to fix their problem: enormous codebases with slow builds and complex C++ code, needing servers that handle massive concurrency.

Its answers: AOT compiled to a single static native binary (no runtime to install — enormously convenient for containers, 2.9); static and strong typing with structural interfaces (3.3 — a type satisfies an interface just by having the methods, no declaration); tracing GC tuned aggressively for low pause times (3.4); and its signature feature, goroutines.

What it teaches — two things. First, that simplicity is a feature you can deliberately choose. Go omits inheritance, exceptions, and (until recently) generics, and its small feature set is intentional: less to learn, fewer ways to write the same thing, so a large team's code stays uniform and readable. It's a direct counter-argument to the assumption that more expressive is better.

Second, a genuinely better concurrency model. A goroutine is a lightweight thread managed by Go's runtime rather than the OS — starting one costs a few kilobytes, so a program can run hundreds of thousands, while the runtime multiplexes them onto a small number of real OS threads (2.3). Combined with channels (typed pipes for passing values between goroutines) it implements message passing rather than shared memory — Go's slogan is "do not communicate by sharing memory; share memory by communicating." That is precisely 2.4's and 3.5's advice — avoid shared mutable state rather than guarding it — built into the language, and it makes concurrent code dramatically easier to get right. Note that Go achieves both concurrency and parallelism (goroutines genuinely run on multiple cores), which is why it took over cloud infrastructure: Docker, Kubernetes, and most of the modern deployment stack are written in Go.

5. Rust — safety without a garbage collector

Created: 2010 at Mozilla (Graydon Hoare), to answer a question everyone had assumed was settled: must you choose between memory safety and native performance?

Its answers: AOT compiled via LLVM (3.1) to native code with no runtime or GC; static and strong typing with a powerful type system (algebraic data types, exhaustive pattern matching, traits, and type inference so it rarely feels verbose); and memory via ownership and the borrow checker (3.4) — compile-time proof of lifetimes with zero runtime cost.

What it teaches. That the trade-off you thought was fundamental may not be. Rust delivers C-level performance and memory safety, and — a bonus that follows from the same rules — freedom from data races (2.4): since the borrow checker permits either many readers or one writer, the discipline that prevents use-after-free also prevents concurrent mutation. Rust calls this "fearless concurrency," and it's the clearest demonstration in mainstream computing of 3.5's thesis: accept constraints at compile time, receive guarantees for free at runtime.

Its cost, honestly: a steep learning curve (the "fighting the borrow checker" phase is real), slower compilation, and — per 3.3's undecidability point — some correct programs the checker rejects, notably cyclic/graph structures, requiring Rc/RefCell or unsafe escape hatches. It is the right tool when performance and safety both genuinely matter (systems software, browsers, embedded, cryptography, high-performance services), and over-engineering for a CRUD API.

6. The comparison at a glance

	C	Python	Java	Go	Rust
Execution	AOT → native	bytecode + interpreter	bytecode + JIT (JVM)	AOT → static binary	AOT → native (LLVM)
Typing	static, weak	dynamic, strong (+hints)	static, strong, nominal	static, strong, structural ifaces	static, strong, inferred
Memory	manual	refcount + cycle GC	tracing GC	tracing GC (low pause)	ownership, no GC
Concurrency	OS threads + locks	GIL (no CPU parallelism)	threads + virtual threads	goroutines + channels	threads, race-free by type
Startup	instant	fast	slow (JIT warmup)	instant	instant
Best at	systems, embedded	data/ML, scripting, glue	large enterprise systems	cloud infra, concurrent services	performance + safety critical
Teaches you	how the machine works	developer time matters	scaling to teams	simplicity, message passing	constraints buy guarantees

7. The expert lens

Every language is a set of answers to the same questions — so learn the questions, not the languages. By now you can interrogate any unfamiliar language with a fixed checklist: How is it executed (AOT, bytecode, JIT)? Static or dynamic, strong or weak, nominal or structural? Manual, refcounted, traced, or ownership-based memory? What's the concurrency model, and does it give parallelism? What does it constrain, and what guarantee does that buy? Answer those five and you understand the language's shape before writing a line — and you can predict its characteristic strengths, failure modes, and even the style of bugs its programs will have. That transferable framework is the real deliverable of Part 3; a new language then takes days, not months.

Language choice is mostly an ecosystem and organisation decision, not a technical one. The languages above are all Turing-complete (1.7) — any can compute anything. In practice you choose on: the libraries and ecosystem for your domain (you use Python for ML because PyTorch is there, not because the language is special); the hiring pool and existing team expertise; operational fit (Go's single static binary versus a JVM's warmup and memory footprint for a serverless function, 3.2); and hard constraints (a 1 ms latency budget rules out an unpredictable GC — 3.4). Engineers who argue language choice on aesthetics are usually arguing about the least important variable. The honest senior answer to "which language should we use?" begins with "what are the constraints, and what does the team already know?"

The industry's direction is unmistakable: constrain more, guarantee more. Trace the arc of this chapter chronologically — C (1972) trusts you completely; Java (1995) removes manual memory management; Go (2009) removes both manual memory and shared-memory concurrency defaults; Rust (2010) removes memory and data-race errors entirely at compile time; TypeScript (2012) retrofits static checking onto a dynamic language (3.7.7). Each step removes freedom and returns a class of eliminated bugs — precisely 3.5's thesis and 3.3's. Given that memory-safety errors still account for the majority of severe vulnerabilities, expect this direction to continue. Being able to articulate what a constraint buys is what lets you evaluate the next language, framework, or lint rule on its merits rather than on novelty.

Next chapter: languages don't exist alone — they come with package managers, toolchains, and the data formats they exchange. Chapter 3.10 covers npm/npx/nvm, pip vs uv, Maven and .m2, lockfiles and semantic versioning, and JSON vs YAML vs TOML vs protobuf.

Recall

• C (1972, for Unix): AOT native, static+weak, manual memory, OS threads. Teaches how the machine really works; still the substrate other languages are written in. Costs: memory-unsafety (~70% of severe CVEs) and undefined behaviour.
• Python (1991, for readability): bytecode+interpreter, dynamic+strong (+gradual hints), reference counting + cycle GC. Teaches that developer time is often scarcer than CPU time; delegates heavy compute to native libraries. The GIL permits concurrency but no CPU parallelism for Python code — use multiprocessing.
• Java (1995, for portability & large teams): bytecode + JVM JIT (warmup), static+strong+nominal, tracing GC. Teaches scaling to organisations; the best-tuned managed runtime. Quirks: String pool, Integer cache (−128…127), class-file versions.
• Go (2009, for simplicity & concurrency): AOT single static binary, static+strong with structural interfaces, low-pause GC, and goroutines + channels — lightweight runtime-scheduled threads with message passing ("share memory by communicating"). Teaches that simplicity is a deliberate feature. Runs cloud infrastructure.
• Rust (2010, safety and speed): AOT via LLVM, no GC, ownership/borrow checker giving compile-time memory safety and freedom from data races at zero runtime cost. Teaches that accepting compile-time constraints buys runtime guarantees.

Self-test: For each language, name its execution model, typing, and memory management. Why does Python's GIL exist and what does it prevent? What is a goroutine and how does it differ from an OS thread? What does Rust's borrow checker eliminate besides use-after-free? What five questions let you characterise any new language?

Quiz Bank

FoundationalCharacterise C, Python, Java, Go, and Rust by execution model, typing, and memory management.

C: AOT-compiled to native; static but weak typing; manual memory (malloc/free). Python: compiled to bytecode and interpreted (CPython); dynamic but strong typing, with optional gradual hints; reference counting plus a cycle collector. Java: compiled to bytecode run by the JVM with a tiered JIT; static, strong, nominal typing; tracing garbage collection. Go: AOT-compiled to a single static native binary; static, strong typing with structural interfaces; tracing GC tuned for low pauses. Rust: AOT-compiled via LLVM to native with no runtime or GC; static, strong, heavily inferred typing; ownership and the borrow checker resolving lifetimes at compile time.

FoundationalWhat is Python's GIL, why does it exist, and what does it prevent?

The GIL (Global Interpreter Lock) is a single mutex in CPython ensuring that only one thread executes Python bytecode at a time. It exists largely because CPython manages memory by reference counting (3.4), which would require every reference-count update to be atomic — prohibitively expensive per operation — so a single coarse lock was simpler and faster for the common single-threaded case. It prevents parallelism for CPU-bound Python code: adding threads to a CPU-heavy Python program yields no speedup, since only one runs bytecode at any instant. Threads do help I/O-bound work (the GIL is released while waiting), and true parallelism comes from multiprocessing (separate processes, separate GILs) or native libraries that release the GIL (NumPy et al.). Recent CPython offers an optional free-threaded build removing it.

AppliedWhat is a goroutine and how does it differ from an OS thread?

A goroutine is a lightweight thread of execution managed by Go's runtime, not the operating system. Creating one costs a few kilobytes of stack (versus an OS thread's megabytes), so a program can run hundreds of thousands of them, and the runtime multiplexes them onto a small pool of real OS threads (2.3) — so switching between goroutines avoids the kernel context switch cost. Goroutines communicate through channels (typed pipes), implementing message passing rather than shared mutable memory — Go's maxim: "do not communicate by sharing memory; share memory by communicating" — which is exactly 2.4's advice built into the language. Unlike Python's GIL-bound threads, goroutines deliver genuine parallelism across cores.

AppliedWhat does Java's Integer cache do, and why does it surprise people?

The JVM pre-allocates and reuses boxed Integer objects for the range −128 to 127, so Integer.valueOf(100) returns the same object every time. The surprise: comparing boxed integers with == (which compares references, not values) gives true for small numbers but false for larger ones — Integer.valueOf(100) == Integer.valueOf(100) is true, while the same at 1000 is false, because outside the cached range new objects are allocated. It exists to reduce allocation for the very common small values. The lesson generalises to Java's String pool, which interns string literals so identical literals share one object — again making == misleadingly work sometimes. Rule: always compare object values with .equals(), never ==.

InterviewRust claims memory safety without a garbage collector. How, and what else does it get for free?

Through ownership checked at compile time (3.4): every value has exactly one owner, it is dropped when the owner leaves scope (a point the compiler knows statically, so it inserts the free itself), and references are borrowed under the borrow checker's rule — either many immutable borrows or exactly one mutable borrow, never both, and no borrow may outlive its value. Because lifetimes are proven statically, there's no GC and no runtime overhead, yet use-after-free and double free become impossible to express. The bonus: the same "one writer or many readers" rule is precisely the discipline that prevents data races (2.4), so concurrent Rust is race-free by construction ("fearless concurrency"). Costs: a real learning curve, slower compiles, and some valid programs rejected (cyclic structures), requiring Rc/RefCell or unsafe.

InterviewWhat five questions let you quickly characterise any unfamiliar language?

(1) How is it executed? AOT-compiled to native, compiled to bytecode and interpreted, or bytecode with a JIT (3.2) — this predicts startup time, peak speed, and portability. (2) What is its type system? Static or dynamic, strong or weak, nominal or structural, with inference (3.3) — predicts tooling quality and where errors surface. (3) How is memory managed? Manual, reference counting, tracing GC, or ownership (3.4) — predicts safety, pause behaviour, and performance profile. (4) What is the concurrency model? OS threads, an event loop, green threads/goroutines, or actors — and crucially, does it permit true parallelism? (5) What does it constrain, and what guarantee does that buy? Answering these gives you the language's shape, characteristic strengths, and even the typical bugs its programs will exhibit — before writing any code.

StaffA team is choosing a language for a new backend service. How should the decision actually be made?

Start by rejecting the framing that this is primarily a technical choice — all candidates are Turing-complete (1.7) and can compute anything, so the decision is dominated by ecosystem, organisation, and constraints. Work through, roughly in order of weight:

(1) Hard constraints first. Is there a latency SLA a tracing GC could violate (3.4)? Is the workload CPU-bound (ruling out Python's GIL and Node's single loop for the hot path) or I/O-bound (favouring Node/Go)? Is startup time critical — serverless, CLI — which penalises JIT warmup (3.2) and favours AOT (Go, Rust, native images)? Memory budget per container (2.9)?

(2) Ecosystem for the domain. The libraries usually decide: ML → Python; cloud/infra tooling → Go; enterprise integration → Java/C#. Fighting a missing ecosystem costs far more than any language feature saves. (3) Team and hiring. Existing expertise is a large, real productivity factor; a language nobody knows imposes months of reduced output and subtle mistakes.

(4) Operational fit. Deployment artefact (Go's single static binary vs a JVM install), observability maturity, container image size, existing CI/CD and on-call familiarity. (5) Long-term maintenance. For a system many engineers will edit for years, static typing's refactoring confidence (3.3) matters more than initial writing speed. Finally, prefer boring and consistent: introducing a new language to an organisation carries permanent costs (tooling, hiring, on-call, standards) that must be justified by a constraint the existing stack genuinely can't meet. The staff answer opens with "what are the constraints and what does the team already run?" — not with a favourite language.

Flashcards

FlashC — one line

1972, for Unix. AOT native, static+weak, manual memory. Thin layer over the machine; substrate of other languages. Cost: memory-unsafety + undefined behaviour.

FlashPython's GIL

One mutex letting only one thread run Python bytecode — needed because reference counting requires atomic updates. Blocks CPU parallelism; use multiprocessing or native libs.

FlashJava String pool and Integer cache

Literals are interned (shared objects); boxed Integers −128…127 are cached — so == misleadingly works for small values. Always use .equals().

FlashGoroutines and channels

Runtime-scheduled lightweight threads (KBs, hundreds of thousands possible) multiplexed onto OS threads, communicating by message passing over channels — real parallelism.

FlashWhat Rust's ownership buys

Compile-time memory safety with no GC and zero runtime cost — and, from the same "one writer or many readers" rule, freedom from data races.

FlashFive questions to characterise a language

Execution model? Type system? Memory management? Concurrency model (and real parallelism?)? What does it constrain and what guarantee does that buy?

FlashThe industry's direction

Constrain more, guarantee more: C → Java (no manual memory) → Go (message passing) → Rust (no data races or use-after-free) → TypeScript (static layer on JS).

Scenario Drill

DrillYour Python data pipeline is CPU-bound and slow. A junior engineer adds 16 threads and reports no improvement, concluding 'Python threads are broken.' Explain what actually happened and give three real options.

The threads aren't broken — they're doing exactly what CPython's design permits. Because of the GIL, only one thread executes Python bytecode at a time, so for CPU-bound work the 16 threads take turns on a single interpreter lock: you get concurrency (interleaving) but no parallelism (2.3), and total throughput is unchanged — sometimes slightly worse from context-switching and GIL contention. (Threads would have helped had the pipeline been I/O-bound, since the GIL is released while waiting on network or disk — which is why the same code pattern helps in some programs and not others, and why the junior's conclusion felt supported.) The GIL exists because CPython's reference counting (3.4) would otherwise need atomic updates on every reference operation.

Three real options: (1) multiprocessing / ProcessPoolExecutor — run separate processes (2.2), each with its own interpreter and GIL, giving genuine parallelism across cores; the cost is inter-process data transfer (pickling), so it suits coarse-grained chunks of work rather than chatty fine-grained tasks. (2)

Push the hot loop into native code that releases the GIL — vectorise with NumPy/Pandas, or use Numba/Cython/a Rust extension; this is the standard "fast glue over fast kernels" architecture of the scientific stack and is often the biggest win for the least change. (3)

Use a different runtime for that stage — PyPy's JIT, or rewrite only the bottleneck service in Go/Rust while keeping orchestration in Python; also consider the free-threaded CPython build if available. Before any of these, profile to confirm which stage is actually CPU-bound (1.5/Part 14) — the fix depends entirely on that. The durable lesson:

know whether your bottleneck is waiting or computing, and know your runtime's concurrency model, because the same intervention that fixes one is useless for the other.