Systems Programming on Tachera W Sasi, Backend & Infra Engineer (Go, Self-Hosted, Observability)

I Want to Understand Computers, Not Just Use Them

Fri, 02 Oct 2026 00:00:00 +0000

—2" tags: [“tachera”, “software-engineering”, “systems-programming”]

I’ve spent a lot of time writing software.

Web applications. Mobile apps. APIs. Backends. Databases. Deployment systems. Developer tools. And lately, more and more infrastructure and very, very low-level stuff, mostly in Zig.

And honestly, I’m starting to suspect that I have a problem.

At some point, I realized something had changed.

I don’t just want to build software anymore.

I want to understand the computer underneath it.

I want to know what happens when a process starts, how memory actually gets used, why a network connection fails, what the operating system is doing, how filesystems work, what happens when a server runs out of resources, and why a distributed system behaves differently from the beautiful little diagram I drew on a whiteboard.

The diagram, of course, assumes everything works.

The real system apparently did not receive the memo.

I want to understand the machine, not just the framework sitting on top of it.

The abstraction is useful until it isn’t

Modern software development is incredibly good at hiding complexity.

That’s one of its greatest strengths.

I can create an HTTP server without thinking about TCP. I can use a database without thinking about disk pages. I can deploy an application without manually configuring a server. I can create a mobile interface without thinking about how pixels eventually reach a display.

That’s great.

Abstraction exists for a reason.

I don’t want to manually implement TCP every time I build a todo app. That sounds like a terrible Tuesday.

But there is a point where abstraction becomes a ceiling.

You can spend years knowing React, Laravel, Next.js, Docker, Kubernetes, or whatever the industry is excited about this month without understanding much about what actually happens underneath them.

And then something breaks.

A connection starts timing out.

A process consumes all the memory.

A deployment works on one machine but not another.

A filesystem fills up.

A request occasionally takes five seconds instead of fifty milliseconds.

A queue gets backed up.

Your logs say absolutely nothing useful.

You stare at the terminal.

The terminal stares back.

Suddenly the abstraction isn’t enough anymore.

You have to go one layer deeper.

And I want to be comfortable there.

I started caring about the layers underneath

This is probably why I’ve become increasingly interested in Go, Zig, Rust, Linux, networking, distributed systems, infrastructure, and developer tooling.

They force me to think differently.

When I’m building something in Go, I find myself thinking about processes, concurrency, memory, networking, files, system calls, binaries, and failure modes.

When I’m writing Zig, I have considerably fewer layers between me and the machine.

Sometimes that’s beautiful.

Sometimes it feels like the computer has finally decided to stop protecting me from my own decisions.

Either way, I’m learning.

When I’m working with Linux, I can’t pretend the operating system doesn’t exist.

When I’m building infrastructure, I have to think about what happens when something goes wrong.

And that’s exactly what I want.

I don’t want software to feel like magic.

I want to understand the magic trick.

Preferably before production catches fire.

This is also why I build things from scratch

I’ve always had a tendency to build things I probably could have just downloaded.

Sometimes that’s objectively inefficient.

If I need file storage, there are dozens of existing products.

If I need deployment infrastructure, there are already massive platforms.

If I need a programming language, there are hundreds of them.

And yet I keep building.

VintLang started because I wanted to understand what it actually means to build a programming language.

BeamDrop exists because I wanted to build a self-hosted storage system.

Ekilie exists because I wanted to understand the infrastructure behind deploying and managing software.

At this point, I should probably learn to leave perfectly good software alone.

But there is something different about building a thing yourself.

You don’t just read about the problem.

You run directly into it.

You discover why the boring decisions matter.

You discover where systems become complicated.

You discover what breaks.

You discover that your beautiful architecture diagram did not account for the disk being full.

And, most importantly, you develop an intuition that you can’t get from reading API documentation alone.

I don’t necessarily expect every project to become a massive company.

Sometimes the project itself is the education.

Sometimes you spend three days building something that already exists because you wanted to know how it works.

That’s not always good engineering.

But it’s excellent curiosity.

I don’t want to memorize more APIs

There is a strange trap in software engineering where becoming more experienced can sometimes mean becoming better at remembering abstractions.

You learn another framework.

Another library.

Another cloud service.

Another ORM.

Another deployment platform.

Another programming language.

Another JavaScript build tool whose name you will forget in approximately six months.

And suddenly your definition of progress becomes:

How many technologies do I know?

I’m becoming less interested in that question.

I’d rather ask:

How much of the system do I actually understand?

If I know five frameworks but don’t understand networking, that’s a problem.

If I know three cloud platforms but can’t explain what happens when a Linux process runs out of memory, that’s a problem.

If I can deploy a Kubernetes cluster but don’t understand why I needed one in the first place, that’s a particularly interesting problem.

Tools are useful.

Understanding is more valuable.

The deeper I go, the more interesting software becomes

The funny thing is that learning the lower layers hasn’t made higher-level development less interesting.

It has made it more interesting.

When I write an API now, I think differently about it.

When I deploy an application, I think about the machine running it.

When I write concurrent code, I think about what the runtime and operating system are actually doing.

When I design a system, I think more about failure instead of just the happy path.

The layers aren’t separate.

They’re connected.

A web request eventually becomes bytes.

Those bytes travel through networks.

Processes consume resources.

Data ends up somewhere on storage.

The operating system manages all of it.

And underneath all of that is hardware executing instructions.

Which is slightly insane when you think about it.

You can write:

fetch("/users")

and somehow that eventually involves electricity moving around inside a machine, packets travelling through networks, operating systems scheduling work, and hardware executing instructions.

And I used to think the interesting part was the React component.

The React component is still pretty cool, though.

I’m not trying to become a “10x engineer”

I’ve never been particularly interested in that idea.

I don’t want to optimize myself into a machine that produces pull requests.

I want to become the kind of engineer who can sit in front of an unfamiliar system and eventually figure it out.

Give me a strange codebase.

Give me a broken server.

Give me an unfamiliar protocol.

Give me a performance problem.

Give me a system with terrible documentation.

I want my first reaction to be curiosity instead of panic.

Although some panic is probably acceptable.

That’s the skill I’m actually chasing.

Not knowing everything.

Knowing how to find out.

Maybe that’s what engineering really is

The older I get as a developer, the less impressive syntax feels.

Writing code is important, but code is only one part of the job.

The interesting part is understanding why the system behaves the way it does.

Understanding constraints.

Understanding trade-offs.

Understanding failure.

Understanding the environment your software lives in.

And understanding enough of the underlying machine that you aren’t completely helpless when an abstraction breaks.

That’s where I want to go.

I still love building web applications.

I still enjoy React.

I still write APIs.

I still use frameworks.

I’m not abandoning abstraction.

I’m just becoming more interested in what exists underneath it.

Because eventually, I don’t want to just be someone who knows how to use computers.

I want to be someone who understands them.

Even if that means occasionally spending six hours debugging something that turns out to be a typo.

And I think that’s a much more interesting journey.

Originally published on Medium.

What Building malloc Taught Me About Memory

Fri, 13 Mar 2026 00:00:00 +0000

—2" tags: [“clang”]

Modern developers rarely think about memory.

We call malloc, new, or let a garbage collector handle everything. Most of the time that’s perfectly fine. But recently I decided to dig deeper and implement a very small version of malloc myself.

Not to replace real allocators. Just to understand what actually happens under the hood.

The result was surprisingly simple and incredibly educational.

This post walks through the core ideas.

Why Understanding Memory Still Matters

Most software today runs on layers of abstraction.

Frameworks → languages → runtimes → operating systems.

That’s powerful, but it also means many developers never see the foundations those layers are built on.

Understanding memory allocation helps with:

• writing faster software
• debugging memory issues
• understanding how runtimes work
• building systems tools
• designing better APIs

Even if you work in higher level languages like Go , these concepts still power everything underneath.

Step 1: Where malloc Gets Memory

When a program runs, memory roughly looks like this:



Code
Globals
Heap ← grows upward
Stack ← grows downward

malloc allocates from the heap.

Under the hood, the allocator asks the OS for more heap space using a system call like sbrk().

Example:



void *ptr = sbrk(1024);

This moves the program break forward by 1024 bytes and returns a pointer to the new memory.

Think of it like extending the end of your program’s heap.

Step 2: The Naive Allocator

The simplest possible allocator would just call sbrk.



void *my_malloc(size_t size) {
 return sbrk(size);
}

But this immediately creates a problem.

If you later call free, the allocator has no idea :

• how big the allocation was
• where the next block starts
• whether a block can be reused

So real allocators store metadata.

Step 3: The Hidden Header Trick

Every allocation secretly stores a small header before the memory returned to the user.

Memory layout:



[ HEADER ][ USER MEMORY ]

The header might contain:



size
is_free
next_block

Example structure:



typedef struct block_header {
 size_t size;
 int is_free;
 struct block_header *next;
} block_header_t;

When the allocator returns memory, it actually returns a pointer after the header.



return (void *)(block + 1);

Which means the user sees:



ptr → usable memory

While the allocator still has its metadata.

Step 4: Tracking Allocations

Blocks are usually tracked using a linked list.



heap_start
 ↓
[block A] → [block B] → [block C]

When malloc runs:

search for a free block big enough
reuse it if possible
otherwise request more memory from the OS

This keeps allocations fast and avoids unnecessary system calls.

Step 5: What free Actually Does

One surprising thing: free usually does not return memory to the OS.

Instead it just marks the block as reusable.



[HEADER free=1][memory]

Future allocations can reuse that block instead of requesting more memory.

What Real Allocators Do Differently

Real allocators (like the ones used by glibc) add several optimizations:

Block splitting



Free block: 100 bytes
Need: 20

Split into:



20 used
80 still free

Block coalescing

Adjacent free blocks merge together to reduce fragmentation.

Large allocation handling

Large allocations often use mmap instead of the heap.

Thread safety

Modern allocators maintain thread local arenas for performance.

What I Learned From This

Building even a tiny allocator reinforced a few important lessons.

Abstractions hide complexity, but the fundamentals still matter

Languages like Go make memory management easier, but the underlying principles are still there.

Performance often comes from understanding the layers below you

Understanding memory layout and allocation patterns helps explain why some code performs better than others.

Systems knowledge compounds

Once you understand memory allocators, many other topics suddenly make more sense:

• garbage collectors
• runtime design
• kernel memory management
• high performance servers

Final Thoughts

You don’t need to write your own allocator for production software.

But building one, even a small version, forces you to think like the runtime.

And that perspective is valuable.

The more you understand the layers beneath your tools, the better engineer you become.

GITHUB => https://github.com/tacheraSasi/malloc.git

Originally published on Medium.

Comptime vs. Macros: Metaprogramming in Zig and Rust

Mon, 10 Nov 2025 00:00:00 +0000

—2" tags: [“rust-macros”, “zig”, “rust”, “comptime”]

Metaprogramming allows code to generate or manipulate other code, often at compile time, boosting flexibility and performance. Two modern languages tackle this differently: Zig with its comptime feature and Rust with macros. Let’s explore both with examples, drawing from recent discussions and developments as of 2025.

Comptime in Zig: Seamless Compile-Time Execution

Zig’s comptime integrates compile-time computation directly into the language, making it feel like regular code. Functions or expressions marked with **comptime** run during compilation, enabling generics, conditional compilation, and more without separate syntax. It’s restrictive by design to avoid complexity, yet powerful for tasks like serialization or ORM.

A simple example: generating a factorial at compile time in Zig.



fn factorial(comptime n: u32) u32 {
 if (n == 0) return 1;
 return n * factorial(n - 1);
}
pub fn main() void {
 const result = comptime factorial(5); // Computed at compile time: 120
 @compileLog(result); // Logs during compilation
}

This runs entirely at compile time, embedding the result in the binary. Recent projects use comptime for auto-generating DLL loading code or erasure coding optimizations. In 2025, discussions highlight how comptime eliminates the need for macros by treating code uniformly.

Macros in Rust: Declarative and Procedural Power

Rust’s macros come in two flavors: declarative (via macro_rules!) for pattern-matching code generation, and procedural for custom syntax extensions. They’re explicit, ensuring type safety and hygiene (no accidental variable captures). Macros like println! or vec! are everyday examples.

Here’s a declarative macro for a simple vector creator:



macro_rules! my_vec {
 ( $( $x:expr ),* ) => {
 {
 let mut temp_vec = Vec::new();
 $(
 temp_vec.push($x);
 )*
 temp_vec
 }
 };
}
fn main() {
 let v = my_vec![1, 2, 3]; // Expands to Vec with pushes
 println!("{:?}", v);
}

This expands at compile time. Advanced uses include deriving traits or composing derives with crates like macro_rules_attribute. Recent 2025 experiments, like “Crabtime ,” even attempt to emulate Zig’s comptime in Rust using macros, showing cross-inspiration.

Key Comparisons

- Simplicity vs. Explicitness : Zig’s comptime is implicit and blends with runtime code, but changes can break callers unexpectedly. Rust macros are explicit, with strong constraints via traits, reducing errors but adding boilerplate.

- Type Access : Zig provides direct type info at comptime, easing generics. Rust macros handle this through patterns or proc macros, but it’s more involved.

-Use Cases : Both enable generics and optimizations, but Zig avoids a separate macro system, while Rust’s is versatile for DSLs.

In 2025, Zig’s approach is praised for reducing complexity, though Rust’s ecosystem offers more mature tools. If you’re building low-level systems, experiment with both. Zig for elegance, Rust for safety.

Thanks for reading! What’s your take on metaprogramming?

Originally published on Medium.