Why a Systems Language?

Scripting languages (Python, JavaScript) hide the machine: memory is managed, types are dynamic, and performance is “probably fine.”

A systems language gives you direct access to memory, precise control over resource lifetimes, and predictable performance — the tools you need to write operating systems, databases, runtimes, and infrastructure. Every concept downstream in this curriculum (pointers, the stack, allocation, threads) is the real model these languages expose.

There are three languages you’ll meet constantly in systems engineering:

C and the Machine Model

C is a thin layer over the hardware: variables live in registers or memory, struct is literally a byte layout, and an array is a pointer plus a length convention. Two ideas define the language:

• Pointers — a variable holding a memory address. int *p = &x; stores the address of x; *p dereferences it. Pointer arithmetic walks memory: p + 1 is the next int, not the next byte.
• Manual memory — you allocate (malloc), you free (free), you own the result. Forgetting to free leaks; freeing twice or using freed memory is undefined behavior that can crash or corrupt anything.

The payoff is that C programs are predictable and tiny — which is why the kernel, most databases, and every language runtime are C. The cost is that C has no safety net: buffer overflows (writes past an array), use-after-free, and memory leaks are the bugs behind most security vulnerabilities.

Pointers, the Stack, and the Heap

To reason about any systems language you need the two memory regions:

• The stack — per-thread, LIFO, fast. Local variables live here; a function call pushes a frame, return pops it. Automatic: no manual management.
• The heap — shared, dynamic, slower. Anything that outlives its allocating function (dynamically sized data, objects shared across threads) lives here, allocated and freed explicitly (or by a language runtime).

A pointer is how stack code reaches heap data. Rust and Go keep the same model but add automatic memory safety — in Go via a garbage collector, in Rust via ownership rules at compile time.

Rust and the Borrow Checker

Rust gives C-level performance with a compile-time guarantee of memory safety. The core mechanism is ownership.

• Every value has exactly one owner at a time.
• Moving a value transfers ownership; the old binding can’t be used.
• You can borrow (&x, an immutable reference) or mutably borrow (&mut x) — but not both at once for the same value.

The borrow checker enforces this at compile time, which means use-after-free, double-free, and data races are compile errors, not runtime bugs. This is the single biggest reason Rust now underpins critical infrastructure (Tokio async runtimes, database engines, cloud tooling) — safety with zero-cost abstraction.

Go and CSP Concurrency

Go’s signature idea is goroutines — lightweight, multiplexed units of execution started with go func(){}, communicating through channels (chan T). This CSP (communicating sequential processes) style makes concurrent programs read like serial ones: “don’t share memory to communicate; communicate to share memory.”

ch := make(chan int)
go func() { ch <- 42 }()   // producer goroutine
v := <-ch                  // consumer; blocks until a value arrives

Go also has a garbage collector, fast builds, and a pragmatic type system, making it the default for cloud-native services (Kubernetes, Docker, Terraform are Go). For systems programming, Go trades a little control (GC pauses, no manual memory) for a lot of productivity.

The C ABI and Interop

All three languages interop through the C ABI — the binary calling convention (how arguments pass in registers, how structs are laid out, how functions are named). This is why you can call C libraries from Rust (extern "C"), Go (cgo), or any language: the C ABI is the lingua franca of system interfaces.

It also explains why “bindings” are really just ABI declarations, and why ABI changes (struct reordering) break binary compatibility.

When to Choose Which

Practice Trajectory

1. In C, allocate a struct on the heap, write to it through a pointer, and free it. Run with ASan (-fsanitize=address) to see what misuse looks like.
2. In Rust, try to compile code with two mutable borrows of the same value — read the compiler’s error, then restructure it.
3. In Go, build a pipeline of three goroutines connected by channels and time it against a serial version.
4. nm and objdump a compiled binary to find symbol names and confirm the C ABI mangling convention.
5. Explain the stack-vs-heap lifetime rule in your own words, then defend which language you’d pick for a new memory-caching server.

When It’s the Right Tool