Home/Writings/Programming

Why Rust for Systems

A practical note on why Rust changes the shape of low-level engineering work.

Figure 1A working loop for technical inquiry: observe the system, reason about its constraints, and build to test the model.

Rust is not interesting because it makes systems programming easy. It is interesting because it makes many failure modes visible before a service is handling real traffic or a tool is chewing through real files.

The ownership model forces design decisions to surface early. Shared state, lifetimes, and mutation stop being ambient hazards and become part of the shape of the program. That friction can feel expensive, but it often replaces a much more expensive debugging session later.

For backend and infrastructure work, the best part is not raw speed. The best part is being able to write fast code while keeping a strong local story about who owns memory, who can mutate it, and where concurrency boundaries actually are.

Continue reading
Systems Programming · 15 min read

From Discord Bots to Flirting with Kernels: My Unorthodox Path into Systems Programming

How a simple Discord bot at age 15 during lockdown taught me more about real engineering than any roadmap ever could. The story of project-driven learning, rejecting shortcuts, and ending up building Rust shells and ptrace tools.

Read note
Systems Design · 12 min read

The Hidden Cost of Abstractions

Why every layer leaks eventually, and why backend engineers should care.

Read note
Engineering · 7 min read

Observability vs Logging

Why logs are useful, but not enough to understand a running system.

Read note