Why I Use C | Prime Reacts

C language’s enduring appeal comes down to a specific kind of control: it sits close enough to how computers actually work to preserve the “mechanical” elegance of the underlying system, without forcing programmers to micromanage every detail by hand. The core claim is that C’s small, powerful toolset—especially features like pointers—lets skilled developers build software with fewer layers of abstraction that turn implementation into a black box.

The discussion starts with a broader frustration: modern languages can accumulate clever features until the result feels like a “blurry deluge” rather than a clear set of primitives. That doesn’t mean rejecting abstraction entirely. Instead, the argument is that abstraction should be judged by what it enables—how much problem-solving power it adds relative to the cost in time, opacity, and uncertainty. Even when using C, there’s still plenty happening under the hood at the CPU and compiler levels, but C’s design keeps the language itself lean, so developers can reason about what matters.

A key comparison point is the “watchmaker” metaphor. Assembly is treated as nearly one-to-one with machine code, like the finest mechanical work where each component has a precise role. High-level languages, by contrast, are likened to stacking black boxes on top of black boxes. The counterweight is that abstraction can still be valuable when it removes tedious manual work—like loops, conditionals, and functions—while leaving the important mechanics within reach.

Zig enters as a modern example of a language that tries to strike that balance. The conversation highlights Zig’s approach to pointer safety and optionality: rather than hiding null-related concerns, it provides language-level syntax that makes “pointer may be null” explicit and manageable. The optional “question mark” is framed as “optional enough”—a small abstraction that reduces common errors without fully erasing the underlying model. Rust and Zig are grouped together on this philosophy, while Go is singled out for lacking the same optional-pointer ergonomics.

The practical tradeoff theme runs throughout: more control often means more pain, and more abstraction often means less time spent on boilerplate but more uncertainty about what’s happening. The speaker’s personal calculus is time-first—choosing tools that don’t demand constant costly tradeoffs. That’s also why the conversation lands on mastery as a long-term motivator: if someone learns a language and immediately hates it, they may not keep programming. But if they haven’t tried alternatives, dismissing them is treated as premature.

The broader takeaway is less about which language wins and more about why certain languages feel “beautiful” to use: C’s minimal primitives, Zig’s explicit optionality, and the shared idea that skilled pointer use can produce “shockingly elegant” code. The appeal is framed as a craft—like drawing with basic tools or building a watch from precise components—where mastery turns complexity into clarity rather than confusion.