Posts

In the previous post, we saw that dynamically linked binaries don’t include library code, they just reference it. Which raises an obvious question: who actually loads that code at runtime, and how does the program find it? The answer is ld.so, the dynamic linker. And it runs before your main() does. The Bootstrap Problem When you execute a binary, the kernel reads its ELF header. One of the fields in that header (stored in the .interp section) contains a path like: ...

Most developers treat compilation as a black box: you put source code in, you get a binary out. But there are actually three distinct stages happening, each with its own job and its own output. Understanding them has made me significantly better at debugging linker errors, understanding dependencies, and reasoning about what ends up in a binary. Let’s walk through what happens when you run gcc hello.c -o hello. Stage 1: The Preprocessor Before the compiler sees a single line of your code, the preprocessor runs. Its job is mechanical: it handles all the # directives. ...

When you need to process a large number of records in Elixir, the instinct is often to wrap everything in a transaction. All-or-nothing semantics, right? Safe by default. Turns out, this is one of those cases where the “safe” choice creates a bigger problem than the one you were trying to avoid. Here’s what’s actually happening under the hood, and a better approach that’s both safer and more efficient. The Naive Approach Let’s say you have a batch job that needs to process thousands of files, calling an external API for each one and saving the result to the database. ...

When you’re building a system that needs to execute many different “actions” (think AI-powered pipelines, data processing jobs, or any multi-step business logic) you quickly face a design question: how do you keep things extensible without coupling everything together? In Elixir, the answer often comes down to two powerful primitives: Behaviours and dynamic dispatch via atoms. Let me walk you through an architecture that elegantly solves this problem. The Problem: Many Actions, One Orchestrator Imagine you have an application that runs multiple independent actions, and that each one takes some input, does some processing, and produces a formatted output saved to a database. You could write each action as a standalone module with its own logic, but then whoever orchestrates them needs to know about every single one. That’s tight coupling, and it makes adding new actions painful. ...