Programming languages
A language is two things at once — a syntax and a runtime. Each study path here treats both. The syntax half is "how do you express the idea idiomatically"; the runtime half is "what does the machine actually do when you run it". Seven languages, ordered by the rough sequence a working engineer tends to want them.
The languages
One card per language. Each describes the shape of its study path — twelve mental models, the runtime, the standard library, concurrency, memory, idioms, tooling.
- 01
Go
The language and the runtimeGoroutines, channels, the M/P/G scheduler, the GC, escape analysis, the runtime. The interview-favourite of cloud-native and infra teams; the language behind Kubernetes, etcd, Cockroach, and Docker.
10 deep dives · 30 min hub + 20 min per dive · day-0 → month-3Role · Backend services, CLI tools, infra - 02
Rust
Ownership, borrowing, zero-costThe borrow checker as a thought tool. Lifetimes, ownership transfer, async (Future / Pin), unsafe and FFI, the memory model. The new systems-language frontier — Cloudflare's Pingora, Linux kernel modules, Firefox internals.
7-day concept path · runtime deep dives in flightRole · Systems, performance-critical, embedded - 03
JavaScript
The event loop, V8, Node, the runtime storyModern JavaScript — closures, prototypes, promises, async/await — and the runtime that ties them together. The Node.js event loop, libuv, V8 inline caches, garbage collection. The differences between Node, Deno, and Bun. The language the web actually runs on.
7-day concept path · V8 internals in flightRole · Frontend, full-stack, scripting
How each language path is structured
Same shape every time. Drilling on one teaches the form; reading three teaches what repeats across runtimes.
- Twelve mental models. The intuitions a fluent speaker of the language has. Tagged by audience tier.
- The runtime, end-to-end. What happens between the source and the silicon — interpreter, JIT, GC, scheduler, memory model.
- The standard library shape. Which collections, which idioms, which patterns. Not API reference — pattern reference.
- Concurrency model. Threads vs. goroutines vs. async, the memory model, the canonical race-free patterns.
- Memory model. Stack vs. heap, escape analysis, ownership (if relevant), GC tuning knobs.
- FFI and the C boundary. Calling into and out of C — every serious language has this, and most engineers never learn it.
- Performance idioms. The handful of patterns that separate "compiles" from "production-ready".
- Tooling. Build, test, profile, debug. The actual day-to-day.
- Common mistakes. Eight bugs that catch every newcomer to the language.
Why a separate category
The "languages" category sits next to the topic-based paths (databases, networking, distributed systems). A real engineer needs both — fluency in one or two languages, plus breadth across the topics those languages are deployed in. The languages category exists for the cases when language fluency is the bottleneck (preparing for a Java-shop interview, picking up Rust as your second systems language, or just getting the runtime mental model that you should’ve had years ago).
Cross-references
- Operating systems. The kernel layer every runtime sits on top of. Useful before any language path.
- Computer architecture. The silicon every language ultimately compiles to.
- Computer networking. Most service code is doing I/O; understanding it pays off in every language.
- Problem-solving. Algorithmic interview prep — the language matters, but the pattern fluency matters more.