Every language that runs on a real machine has to answer the same short list of questions. Who frees the memory? What happens when an operation has no defined meaning? How does a value cross the boundary into code compiled from another language? How does a structure become a sequence of bytes on a wire? The answers differ sharply, and each answer buys something and costs something else.

This cluster takes one such concern per note and reads it across several languages at once. The theory behind each concern already lives in Programming Language Concepts; these notes are about what the theory turns into when it meets a compiler, a linker, and a network. They lean toward the concerns a systems, networking, or security engineer runs into: the machine contract, the wire, and the trust boundary.

The generics spine

The longest arc here follows one question through eight notes: what happens to a type parameter between the source you write and the machine code that runs. Start with the survey, then take the pieces in order, because each one is a different place the same design decision surfaces.

The machine contract

The concerns that exist because the code eventually becomes instructions on a specific machine. Every note here is about a promise the language makes to hardware, an operating system, or another language’s compiler.

Runtime behavior

What the program does once it is running, when an operation fails, when two threads reach the same value, or when the text is not ASCII.

Compiling and organizing code

How source becomes a unit the compiler and the package manager can both reason about. The first note is the compile-strategy half of the generics spine above.

Toolchain and ecosystem

The concerns that start outside your source tree, where most of the code in a modern program comes from.

The comparative layer is meant to grow. Any concern that several languages must answer, and answer differently, belongs here.