Shenawy's Blog

Why Neovim in the Age of Agentic Coding?

Thu, 16 Jul 2026 00:00:00 GMT

Introduction

I’ve been writing code for about 4 years now. In that time, I started like any CS student, with VSCode. If I wanted to write code, I’d type it like any other text. If I wanted to run my code, I’d hit a shortcut and VSCode would run it. I didn’t really understand how the code worked. I just knew it ran.

How Neovim and I met

A while ago, I started watching a YouTuber named ThePrimeagen. He was a Software Engineer at Netflix at the time, and every time I watched his streams on Twitch or YouTube, my eyes couldn’t keep up with what he was doing. Aside from his absurdly fast typing speed and his unusual keyboard (dvorak), that wasn’t the main reason he was fast. The main reason was his text editor: Neovim.

What is Neovim

In case you don’t know, Neovim is a fork of another text editor called Vim. Vim is very old, created in 1991. It was itself an improvement over an even older text editor called Vi.

There used to be a war between Vim and Emacs, but those battles are mostly over, though they still linger in programming culture. If you Google “Vim” for example, it’ll ask “Did you mean emacs?”, and vice versa.

Neovim runs in the terminal. This means there’s essentially no GUI, and it draws its UI on the terminal.

For several reasons, Neovim is very fast. It starts in under 100ms depending on your CPU, even with dozens of plugins installed.

Neovim is a modal text editor. You switch between different modes to do different things. You can’t just hold Shift and arrow down to make a selection; you need to enter Visual Selection Mode. If you want to type, you enter Insert Mode. If you want to navigate, you use Normal Mode. That’s why the learning curve can be a bit steep.

The goal of this article isn’t to teach you how to use Neovim. There’s a saying: “You don’t know what you don’t know.” It sounds obvious, but it’s true. You would never try Neovim if no one told you about it, because you do not know it exists.

It’s like someone who has only ever used a regular screwdriver; they wouldn’t think to ask about an electric screwdriver. The job gets done; that’s enough. It’s the same with Neovim: if you only use VSCode, you won’t know there’s a completely different way to write code, and you’ll keep thinking VSCode is the ultimate truth.

And since I believe a picture is worth a thousand words, I decided to show you some things you can do with Neovim that are hard to do in other editors.

Practical Examples

Here’s something practical. You’ve probably needed something like this before, using Visual Block Mode to edit multiple lines at once:

Or, for example, quickly changing if statements to a switch statement using the substitution command:

You can also add new plugins. For instance, if you want to exchange function arguments, you can use the mini.ai plugin:

There’s also a plugin called flash.nvim. It lets you do remote operations, for example, you can go delete something somewhere else and come back to paste it where you were:

Any Agent Could Do This…

All these movements are really cool and make you fast and all. If you were to write a single prompt, all of these things could be done anyway. Of course, by the time you finish writing the prompt, it’d probably take longer than actually doing it yourself, but it would still get done, and you wouldn’t have to learn a new text editor from scratch.

The benefits of Neovim are not about speed. That’s a big factor, but for me, it was not the biggest benefit.

The biggest benefit is the ecosystem. Once you start using Vim motions, you will not want to use anything that does not support them. You’ll find them everywhere: your Browser (Vimium), your File Manager (ranger/lf/yazi), your Shell (set -o vi in zsh/bash), tmux, git, and even other IDEs (VS Code Vim extension, JetBrains IDEAVim). They all support Vim motions. It’s one unified movement system for everything you do on your computer.

Another benefit is that you get used to the CLI. You basically live in it; you start feeling like anything else is slow and bloated. You’ll be comfortable combining different CLI tools with pipes, managing sessions with tmux, searching and replacing with grep and sed, handling git quickly, working on remote servers over SSH without opening another application. The CLI gives you complete control over everything.

Another thing is the community. Whatever you’re building, you’ll find massive support. I made xdg-nvfilechooser, for example, and even though the project isn’t complete, I got a lot of support because people liked the idea.

There’s a big overlap between the Neovim community and other “cracked” programmer communities. You’ll often find that Neovim users are people with deep experience in their field. I’ve noticed this, and these are people you can actually learn from.

For example, I would never have gotten good at Rust without Jon Gjengset’s YouTube channel and his books. Guess what editor he uses.

There’s also sphaerophoria. He uses Zig and Rust all the time, and I don’t understand 99% of the code he writes because he’s on another level entirely. Guess his editor too.

You’ll also find overlap between the Neovim community and Nix. If you don’t know, Nix is a Linux package manager. One resource that helped me was the Tweag YouTube channel. Guess their editor.

This doesn’t mean that once you use and master Neovim, you’ll automatically become a code master with no equal. The point is that people who like using Neovim tend to have a certain mindset, and I enjoy learning from people with that mindset. They have passion, a love for what they do.

Conclusion

If you want to learn more about Neovim, I’d advise you not to start with the editor itself. Start with any extension that implements Vim motions in the editor you already use. Once you get used to it, you can dive into the text editor itself.

Enter the Arena

Sun, 12 Jul 2026 00:00:00 GMT

Why do we use Python? JavaScript? Java? Dart? Any first-year CS student can tell you these languages are slow compared to languages like C. If we want our software to run as fast as possible, why do we use these languages at all when we could just use C++ for everything?

The answer is simple: ease of use. These languages are very easy to use, their syntax is simple, they read almost like English, they’re usually portable, and, most importantly, they’re garbage collected.

Garbage collected means the coder doesn’t have to think about memory. They can (ironically) forget about it entirely. If I write a program that uses 100 kilobytes, I don’t need to free that 100 kilobytes myself, because I know my language’s runtime will save me and free that memory at some point on its own.

It wasn’t always like this. Most coders in the past had to use manual memory management. You’d tell the computer: I’m going to make an object. This object, all together, is 100 kilobytes. The computer’s only job is to hand you back that memory so you can put your data in it. It’s not the computer’s job to free that memory later, that’s on you.

For this article, I’ll assume you already have some idea of what the heap, the stack, and malloc/free are.

Stack Based Allocations

When you first learn to program, you learn there are two ways to allocate memory: on the stack or on the heap. You probably learned that the stack is faster because memory sits contiguously, while the heap is slower because memory is scattered around. And that you use the heap when you don’t know ahead of time how big an object needs to be, that’s when you reach for dynamic memory. That’s not entirely accurate, you can easily use the stack for dynamic memory too as we’ll later see.

Take a look at the code below:

def three():
    e = 3
    f = 3
    g = 3


def two():
    b = 2
    c = 2


def one():
    a = 1
    two()

def main():
    one()

if __name__ == "__main__":
    main()

If we look at Python’s bytecode for this on Godbolt, and focus on three, we get this:

Disassembly of <code object three at 0x5676616f8980, file "example.py", line 1>:
  1           RESUME                   0

  2           LOAD_SMALL_INT           3
              STORE_FAST               0 (e)

  3           LOAD_SMALL_INT           3
              STORE_FAST               1 (f)

  4           LOAD_SMALL_INT           3
              STORE_FAST               2 (g)
              LOAD_CONST               1 (None)
              RETURN_VALUE

Notice there are 3 stores (allocations) but no deallocation at all. That’s because the whole stack frame gets torn down at once, and that counts as your deallocation.

All the variables we create get wiped out together, because the entire stack frame gets torn down together.

So here’s a question: why don’t we just use the stack for everything? The stack is extremely efficient. It does a single allocation per object, and a single deallocation for all the objects at once, once the stack frame’s lifetime ends.

The whole point isn’t really that we don’t want dynamic memory, dynamic memory is actually possible on the stack, through a C stdlib API called alloca. What we actually want is for our memory to outlive the stack frame. We don’t want the memory we allocate to disappear the moment the function call ends.

Heap Based Allocations

On the other side, we have the heap. The usual way to allocate on the heap is through the C API malloc and free.

Their API isn’t hard to understand, and the point of this article isn’t to teach you malloc and free, it’s to teach you advanced memory allocation techniques.

The idea behind malloc and free is simple. Need memory? Ask for it with malloc. Don’t need it anymore? Free it with free. If you’re disciplined about this pattern, your program can never leak memory.

This paradigm is nice. Every malloc should be paired with a free. But in practice, it’s not always this simple.

Manual Memory Management: Problems

Our friends in cybersecurity know that a big part of their field exists just to find code that misuses malloc and free. Things like freeing memory twice (a double free), which can end up letting you write to memory that’s now been reallocated for something else entirely without you even realizing it. Or malloc-ing a buffer that’s smaller than the data you’re about to put in it, so you write past the buffer’s bounds and corrupt whatever memory is next to it. So you really have to be careful when using this API.

Even so, every free still has to search for the right chunk of space, update its internal metadata, and deal with issues like fragmentation. In other words, even without a syscall, it’s still not a free operation.

The fact that the operation can be somewhat expensive isn’t the only downside of this paradigm. If you have a graph made entirely of objects, figuring out which node to free first can be genuinely hard, especially if the graph is cyclic.

Even if you use the API perfectly, there’s still a cost you pay. The allocator might need to request fresh memory from the OS, which tends to be expensive since it usually involves a system call. But most modern allocators don’t make a syscall for every single malloc. Instead, they request one big chunk of memory upfront, and then divide it up themselves across the smaller allocations your program asks for.

300,000 Rats

Imagine you’re building a game. Something like A Plague Tale: Requiem. It can have more than 300,000 rats on screen at once. Setting aside how hard that already is to render on the GPU, the CPU still needs to track each object individually for the rat’s own logic. In reality, not every rat is its own object (there’s merging involved most definitely) but let’s assume that in our hypothetical game, every rat has to be its own object.

How would we create these objects? If we did 300,000 allocations one by one, we’d literally never finish in time. Now imagine there’s also an ability in the game that lets you kill every enemy on screen at once. When you kill them, they all disappear. Are we going to do 300,000 calls to free?

The better solution here: since these enemies are spawned all at once, and disappear all at once too, we should do a single allocation for all the enemies, and a single deallocation for all of them as well. Because these enemies’ entire lifespans are tied together. Their lifetimes are linked.

Lifetimes

Anyone who’s learned Rust probably just got PTSD flashbacks seeing that subtitle. We won’t go too deep into lifetimes since they’re a complicated topic, but let’s talk about them at a high level.

Put simply: an object’s lifetime is the span of time during which that object is considered valid and usable.

For example, I can’t use a_1 or a_2 after their scope (the closing bracket) ends.

{
    let a_1 = 1;
    let a_2 = 2;
}

Like this:

{
    let a_1 = 1;
    let a_2 = 2;
}

// Invalid.
console.log(a_1);

Setting aside JavaScript’s own scoping quirks, this concept exists in pretty much every programming language today.

If we want to create a new lifetime, we start a new scope. So we can track our lifetimes, let’s name them say, a and b.

// lifetime a start
{
    let a_1 = 1;
    let a_2 = 2;
}
// lifetime a end

// lifetime b start
{
    let b_1 = 1;
    let b_2 = 2;
}
// lifetime b end

Notice something? The two numbers inside each scope are tied to each other. Their lifetimes are linked. The moment both numbers go out of scope, we can discard them all at once, since neither one will outlive the other anyway. If one of the two numbers reaches the end of its lifetime, the other one necessarily has to end its lifetime too, because they were both created in the same scope.

The stack works exactly this way, as we saw earlier. Every variable inside a stack frame has its lifetime tied to the lifetime of the frame itself.

Here’s what we actually want: we want a way to tie the lifetimes of our objects together, the same way the stack does, avoid the headaches of malloc and free, and still decide for ourselves exactly when that lifetime ends.

The Arena Allocator

The solution to our problem is arena allocation. The whole idea is that you start by doing a single malloc for one big buffer, and then you use that region to add your objects into. The objects can be of any type, and any size. And when you’re done with the arena, you just reset that memory in one go.

There are many techniques for building arenas, we’ll implement the most well-known kind, called a bump allocator. We’ll use C.

The Arena Struct

This is the first thing we’ll build. All we need inside our struct is a buffer to hold our data, and we need to know the size of that buffer.

#include <stddef.h>

typedef struct Arena {
    unsigned char* buffer;
    size_t buffer_size;
} Arena;

int main(int argc, char* argv[]) {
    return 0;
}

To create an arena, we need a function. We’ll call it Arena_malloc, and it’ll return a pointer to the struct we’re creating.

Arena* Arena_malloc(size_t buffer_size) {
    // One malloc to create the struct.
    Arena* arena = malloc(sizeof(Arena));
    arena->buffer_size = buffer_size;

    // Another malloc to create the buffer.
    arena->buffer = malloc(buffer_size);
    return arena;
}

Now, if we want to create a new arena, this is all it takes:

int main(int argc, char* argv[]) {
    Arena* a = Arena_malloc(1024);
}

This creates a buffer that’s 1024 bytes in size.

Right now, the buffer looks like this:

Arena Allocation

Now, how do we actually use our arena?

We’ll write another function called Arena_allocate. All this function does is take a size parameter, and with that size, it places the memory we need into the buffer we’ve created.

If, say, we go and allocate a struct called Player that’s 120 bytes, the buffer would end up looking like this:

Now we need something that tells us how full our buffer currently is. We’ll add a buffer_offset field to the Arena struct.

typedef struct Arena {
    ...
    size_t buffer_offset;
} Arena;

CPU Alignment

Now, there’s one more thing we need to learn: CPU alignment.

CPUs like to read memory in a specific way. If you have an int (usually 4 bytes), the address of its first byte needs to be an address divisible by 4.

So if we picture our memory as addresses running from 0 to 1024, and we’ve used up to address 493, then the next address where we’re allowed to place our int is 496, since that’s the nearest address divisible by 4.

So what happens with the 3 addresses right after 493? We need to fill them with something, we fill them with what’s called padding.

So how do we calculate the alignment of our data types? You might think that since a data type’s address needs to be divisible by its size, we could just use sizeof.

Unfortunately, it’s not quite that simple. Imagine you have something like this:

struct Player {
    char x;
    int y;
};

And our memory ends up looking like this:

0    x
1    padding
2    padding
3    padding
4    y
5    y
7    y
8    y

sizeof on this struct gives us 8. But in reality, we need this struct’s address to start on an address divisible by 4.

The general rule of thumb for alignment is that a struct’s alignment equals the size of the largest data type inside it, in this case, the largest data type is the int, so the alignment is 4, meaning this struct needs to start on an address divisible by 4.

Back to allocation. To allocate inside our buffer, we need to know both the size of the struct we’re allocating and its alignment, so we know exactly which address to place it at within our buffer.

void* Arena_allocate(Arena* a, size_t struct_size, size_t struct_alignment) {
    ...
}

We need a better way to visualize our buffer. Our buffer doesn’t exist in memory all by itself.

If, say, our memory is 4096 bytes total, and the buffer itself is 1024 bytes, it might look something like this:

So, what do we actually need to do to allocate? We need to start from the very beginning of the buffer’s address, add the offset (how much of the buffer is already used), and also add padding, so the struct ends up properly aligned.

The first thing we need to do is figure out, starting from the offset, how much we need to add to become aligned. Say our offset is 5, and the alignment is 4, we calculate 5 % 4 = 1. That means our current offset is 1 byte past the correct alignment. So, to reach the next valid alignment, we need to subtract that result from the alignment itself: 4 - 1 = 3. That means we need to add 3 bytes to our current offset to land on the correct address.

But what happens if you’re already at a valid alignment? Say the offset is 8, and the alignment is 4. You’d calculate 8 % 4 = 0, and subtract that from the alignment, giving you 4, but that’s wrong. That’s why, at the very end, we need to take the mod of our result one more time: 4 % 4 = 0. And that’s our correct answer.

The code ends up looking like this:

void* Arena_allocate(Arena* a, size_t struct_size, size_t struct_alignment) {
    size_t padding =
        (struct_alignment - (a->buffer_offset % struct_alignment)) %
        struct_alignment;

}

This gives us the padding needed to make the address aligned.

Arena Allocation: Continued

We want to make sure our struct will actually fit inside our arena. We check whether our offset plus the padding plus the struct’s own size is less than the arena’s total size.

We’ll write this line:

if (a->buffer_offset + padding + struct_size > a->buffer_size) {
    return NULL;
}

To calculate the address, we do some pointer arithmetic. We add the padding to the address of the buffer’s pointer. We also add the current offset, which tells us how much of the buffer we’ve already used.

void* placement_address = a->buffer + a->buffer_offset + padding;

Then, we add the padding we just calculated to our offset, plus the size of the struct we’re adding.

a->buffer_offset += padding + struct_size;

Finally, we return our address.

return placement_address;

And here’s the complete implementation of the allocation function:

void* Arena_allocate(Arena* a, size_t struct_size, size_t struct_alignment) {
    size_t padding =
        (struct_alignment - (a->buffer_offset % struct_alignment)) %
        struct_alignment;

    if (a->buffer_offset + padding + struct_size > a->buffer_size) {
        return NULL;
    }

    void* placement_address = a->buffer + a->buffer_offset + padding;

    a->buffer_offset += padding + struct_size;

    return placement_address;
}

That’s it. That’s the whole implementation of our allocator.

Reset & Free

What do we do if we want to reuse our arena for something else? We’ll write another function called Arena_reset. You’d probably expect this implementation to be complicated, but it’s not. Here’s the whole thing:

void Arena_reset(Arena* a) {
    a->buffer_offset = 0;
}

Think about it this way: if we reset our offset back to zero, what happens? The next time we allocate, we’ll simply write over whatever data used to be there. You could think of it as treating our old data as garbage values, and just writing right over it.

That said, we still haven’t freed the buffer’s memory itself. We need a function for that too.

void Arena_free(Arena* a) {
    // Free the buffer owned by the arena first
    free(a->buffer);
    // Free the arena struct itself
    free(a);
    // `a` is now dangling.
}

Arena Usage

Now for the fun part, how do we actually use our arena? Imagine we’re building a game. On every frame of the game, we need to allocate some ammo, say, some bullets.

The first thing we’ll do is create a struct called Bullet.

typedef struct Bullet {
    float x, y;
} Bullet;

If we wanted to allocate one, we’d do something like this:

int main(int argc, char* argv[]) {
    Arena* a = Arena_malloc(1024);

    Bullet* b = (Bullet*)Arena_allocate(a, sizeof(Bullet), _Alignof(Bullet));

    b->x = 10.0;

    return 0;
}

The odd-looking thing in this code is _Alignof. It gives us the alignment of any type.

We start by creating our arena, and Arena_allocate gives us back an address inside the buffer as a void*. All we need to do is cast that address to a pointer of our own type. What that’s really saying is: “I don’t want to treat this address as raw bytes anymore, this address is meant to hold the bytes of a Bullet struct.”

After that, we write the data we want into that address. In this case, we set x to 10.0.

Writing this code out is a bit annoying, so we can make a macro to make it easier to write.

#define ARENA_ALLOCATE(arena, Type)                                            \
    ((Type*)Arena_allocate((arena), sizeof(Type), _Alignof(Type)))

int main(int argc, char* argv[]) {
    Arena* a = Arena_malloc(1024);

    Bullet* b = ARENA_ALLOCATE(a, Bullet);

    b->x = 10.0;

    return 0;
}

Now let’s write our game loop.

int main(void) {
    Arena* a = Arena_malloc(MAX_BULLETS * sizeof(Bullet) + 64);

    // so gcc doesn't optimize this out.
    volatile float sink = 0;

    for (int frame = 0; frame < FRAME_COUNT; frame++) {
        int bullet_count = (frame % MAX_BULLETS) + 1;

        Bullet* bullets = (Bullet*)Arena_allocate(
            a, sizeof(Bullet) * bullet_count, _Alignof(Bullet));

        for (int i = 0; i < bullet_count; i++) {
            bullets[i].x = i * 10.0f;
            bullets[i].y = frame * 5.0f;
        }

        sink += bullets[bullet_count - 1].x;

        Arena_reset(a);
    }

    printf("done, sink = %f\n", sink);
    Arena_free(a);
    return 0;
}

We create a single arena before the loop starts. On every frame, we allocate the bullets specific to that frame, use them, and then reset the arena at the end of the loop.

Then, we reuse that same arena on the next frame.

Benchmark: Arena vs malloc

Now, let’s compare our allocator against malloc. This is the exact same version, but using malloc instead.

#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>

typedef struct Bullet {
    float x, y;
} Bullet;

#define FRAME_COUNT 2000000
#define MAX_BULLETS 50

int main(void) {
    // same thing
    volatile float sink = 0;

    for (int frame = 0; frame < FRAME_COUNT; frame++) {
        int bullet_count = (frame % MAX_BULLETS) + 1;

        Bullet* bullets = (Bullet*)malloc(sizeof(Bullet) * bullet_count);

        for (int i = 0; i < bullet_count; i++) {
            bullets[i].x = i * 10.0f;
            bullets[i].y = frame * 5.0f;
        }

        sink += bullets[bullet_count - 1].x;

        free(bullets);
    }

    printf("done, sink = %f\n", sink);
    return 0;
}

We’ll use hyperfine to compare the two.

Here are the compile commands we’ll use:

gcc -O2 -std=c11 -o arena_bin arena.c

gcc -O2 -std=c11 -o malloc_bin malloc.c

And the run command:

hyperfine --warmup 3 ./malloc_bin ./arena_bin

Here are our results:

Benchmark 1: ./malloc_bin
  Time (mean ± σ):      19.0 ms ±   1.9 ms    [User: 18.6 ms, System: 0.5 ms]
  Range (min … max):    17.9 ms …  36.8 ms    141 runs


Benchmark 2: ./arena_bin
  Time (mean ± σ):      10.0 ms ±   0.3 ms    [User: 9.7 ms, System: 0.5 ms]
  Range (min … max):     9.5 ms …  12.0 ms    244 runs

Summary
  ./arena_bin ran
    1.90 ± 0.20 times faster than ./malloc_bin

Credits

This article wouldn’t have been possible without this fantastic talk by Ryan Fleury.

This C++ implementation was also extremely helpful.

Imaginary Numbers Are Real

Mon, 23 Mar 2026 00:00:00 GMT

Math as a field has existed since the beginning of history. From the moment humanity started building civilization, numbers existed, but not all the numbers we know today existed. We started with the integers: $1, 2, 3, 4, 5, . . .$

These numbers were enough until we started running into problems calculating ratios. Around that time, fractional numbers, Fractions, came into existence to solve some of the problems we were facing.

Later we discovered that not every number can be written as a fraction, like $\sqrt{2}$ for example. This period was a bit rough, because some cultures considered whole numbers sacred, believing that everything in the universe could be written as whole numbers and fractions.

The Evolution of Numbers

There’s an old story that tells of the Greeks, where a group followed a philosophical and religious school called the “Pythagoreans”. They discovered something that shocked them: the length of the diagonal of any square with a side length of 1 equals $\sqrt{2}$ . It can’t be written as a fraction. An irrational number. The person who discovered this was named “Hippasus”, and the story goes that the Pythagoreans killed him for saying so (most likely by drowning him).

And this is the pattern we’ll keep seeing throughout this story: every time a new kind of number was discovered, people resisted it at first.

After that, our next new invention of numbers was negative numbers and zero. These numbers also faced resistance, because if you really think about it: what does it even mean to have -5 of something?

People tried as hard as they could to avoid writing anything as negative. So if you had, say, $a + b - c = 0$ , you’d write it as $a + b = c$ instead.

I have 5 apples. There’s nothing in the universe that’s negative something of something.

Anyway, that’s the new system of numbers we have. Positive numbers, negative numbers, irrational numbers, and zero.

The Equation

We stayed like this for a while. And mathematicians, as usual, kept solving more and more complex equations. Until one of them arrived at an equation that no one could solve with any existing numbers, and was left standing in front of it not knowing what to do. That equation was:

$f (x) = x 2 + 1$

Now we have a problem. Roots are the values that, when you plug them into the equation, make the equation equal zero. Someone once proved this:

Polynomials of degree $n$ have exactly $n$ roots.

This proof is so important that it was named the Fundamental Theorem of Algebra. They called it that because it’s one of the most important facts that all of algebra is built on.

This proof says that this equation must have two numbers that make it equal zero. No argument.

But if you look at the graph, you won’t find any point that equals zero. That means the Roots exist, just not among the numbers we know. That’s exactly the problem.

If we look at the function, we won’t find any point where it equals zero.

See how this function never touches the X axis at all:

If we try to solve:

$x 2 + 1 = 0$

$x 2 = - 1$

$x = \pm\sqrt{-1}$

We get some very strange numbers.

Imaginary Numbers

The root of negative one? Even worse, negative the root of negative one? Well, there are two solutions to the equation, but unfortunately neither one makes sense. These numbers kept showing up in mathematical solutions all the time. Some people got used to them, and others assumed that whenever these numbers showed up, it meant there was no solution to the equation they were solving.

We called these numbers imaginary numbers. One of the worst names on the planet, because if you tell someone a number is “imaginary,” they’ll assume it “doesn’t exist” or that it’s some kind of hack you use just to solve your equations. Some people have suggested we call them “lateral numbers” or “elevated numbers” instead, for reasons that will become clear soon.

Since these numbers keep showing up everywhere, what if we added them to our number system? It wouldn’t be the first time we’ve had to adjust our system. But we can’t just add anything willy-nilly. If these numbers are actually going to be useful, they need to obey the existing laws of algebra.

With ordinary numbers, we can split up roots like this

$\sqrt{2\times3} = \sqrt{2} \times \sqrt{3}$

Does that work for imaginary numbers?

$\sqrt{-25} = \sqrt{25}\times \sqrt{-1} = 5\sqrt{-1}$

What about addition and subtraction?

$2 x + 3 x = 5 x$

And for imaginary numbers?

$2\sqrt{-1} + 3\sqrt{-1} = 5\sqrt{-1}$

It looks like our strange new numbers work perfectly fine with every mathematical operation we’ve tried. But how do we write them?

People agreed on a way to write imaginary numbers. Every imaginary number can be written as a real number multiplied by $\sqrt{-1}$ . This number is so special that we gave it its own symbol: $i$ 1.

The Complex Plane

Now, we want a way to add our numbers to the system so that we can write functions and graph them. We’ll sacrifice our Y axis and put our imaginary numbers on it like this:

This is our new coordinate system, with real numbers on the horizontal axis and imaginary numbers on the vertical one:

Notice something about this system.

Take $1$ as an example. What happens if you multiply this number by $i$ , or by $\sqrt{-1}$ ?

You’d get $1 \times \sqrt{-1}$ , which is $\sqrt{-1}$ . Now what if you multiply $\sqrt{-1}$ by $\sqrt{-1}$ ? You’d get $\sqrt{-1}^2$ , which is -1. What if you do it again? You’d get - $\sqrt{-1}$ . Multiply once more and it goes back to 1.

\begin{aligned} 1 &\times \sqrt{-1} &&\;\;\;\;= \sqrt{-1} \\ \sqrt{-1} &\times \sqrt{-1} &&\:\;\;\;= -1 \\ -1 &\times \sqrt{-1} &&\;\;\;\;\;\;\;= -\sqrt{-1} \\ -\sqrt{-1} &\times \sqrt{-1} &&\,= 1 \end{aligned}

In other words

\begin{aligned} 1 &\times i &&= i \\ i &\times i &&\:\;\;\;= -1 \\ -1 &\times i &&\;\;\;= -i \\ -i &\times i &&\,= 1 \end{aligned}

\begin{aligned} i^1 =&\;\; i\\ i^2 =& -1\\ i^3 =& -i\\ i^4 =&\;\;1\\ i^5 =&\;\;i\\ \end{aligned}

$. . .$

And this pattern repeats forever.

See how multiplying by $i$ rotates the numbers in a full circle:

Complex Numbers

Now we have two kinds of numbers: real numbers, whose set is denoted $\Reals$ , and imaginary numbers, whose set is denoted $ℑ \Im$ . The set of imaginary numbers looks a lot cooler, I know. And when we combine them together, we get a third kind called complex numbers, $\mathbb{C}$ .

We found a way to combine these two sets by placing real numbers on the X axis and imaginary numbers on the Y axis. But how exactly do we place a point on this graph of ours?

The notation everyone uses is to add the two numbers together. This makes the algebra for these numbers much easier.

For example, if we want the point at $(2, 3)$ , we’d write it as $2 + 3 i$ . Combining a real number with an imaginary number like this gives you a complex number.

For example, the point $2 + 3 i$ is placed on the graph like this:

Operations on Complex Numbers

Now that we know what complex numbers are, let’s look at how we work with them. We won’t be talking about real numbers alone, or imaginary numbers alone. We’ll talk about the complex whole, both parts together.

The basic rule is simple: real with real, and imaginary with imaginary.

Addition

$(2 + 3 i) + (1 + 2 i)$

$= (2 + 1) + (3 i + 2 i)$

$= 3 + 5 i$

Exactly like adding any two things of the same kind. Real numbers together, and imaginary numbers together.

Subtraction

$(5 + 4 i) - (3 + 2 i)$

$= (5 - 3) + (4 i - 2 i)$

$= 2 + 2 i$

The exact same idea.

Multiplication

Multiplication is a bit more interesting. We multiply just like we would any two binomials, but we need to remember that $i 2 = - 1$ .

$(2 + 3 i) (1 + 2 i)$

$= 2 + 4 i + 3 i + 6 i 2$

$= 2 + 7 i + 6 (- 1)$

$= 2 + 7 i - 6$

$= - 4 + 7 i$

Notice that $6 i 2$ turned into $- 6$ , meaning an ordinary real number. This isn’t a mistake, this is exactly what’s supposed to happen. The imaginary and real numbers mix together during multiplication in a perfectly consistent way.

The Elephant in the Room

We now understand the basic operations on complex numbers. So here’s a question: where are the roots we were talking about here? If our equation is supposed to equal zero at two points, where are those two points?

Look at our equation:

$f (x) = x 2 + 1$

How many variables are in this equation of ours? We have one, $x$ , which is our input, and we have $f (x)$ , which is our output. If $x$ equals 2, for example, then $f (x)$ equals $22 + 1$ , which is $5$ .

If we bring in our imaginary numbers, then we now have an extra variable. So the number of variables we have becomes 3. Two of them are input, and only one is output.

Our function is now called a complex function, because it takes a complex number rather than a real one.

To understand the idea, let’s take a simpler function as an example:

f (x + i y) = x + 5

Notice that our imaginary part is now $y$ , not $x$ .

So how would we graph this function? First, let’s plug in a few numbers.

\begin{aligned} f(\textcolor{#4488ff}{0} + \textcolor{#ff4444}{0i}) &= \textcolor{#4488ff}{0} + 5 = \textcolor{#44cc88}{5} \\ f(\textcolor{#4488ff}{1} + \textcolor{#ff4444}{1i}) &= \textcolor{#4488ff}{1} + 5 = \textcolor{#44cc88}{6} \\ f(\textcolor{#4488ff}{2} + \textcolor{#ff4444}{2i}) &= \textcolor{#4488ff}{2} + 5 = \textcolor{#44cc88}{7} \\ f(\textcolor{#4488ff}{3} + \textcolor{#ff4444}{3i}) &= \textcolor{#4488ff}{3} + 5 = \textcolor{#44cc88}{8} \end{aligned}

As you can see, we have 3 numbers changing. 3 Variables. If we want to graph this function of ours, we’ll need to draw it as a 3D graph, and it’ll look like this:

xxyy

Notice that the output of this function depends only on the real part, which is $x$ . No matter how much you change $y$ , the output won’t change, because the nature of this function’s output is that it depends only on the real part, even though it takes the imaginary part as input as well.

Let’s go back to our original function, which we agreed would be $f (x + i y) = (x + i y) 2 + 1$ .

Let’s plug in numbers the same way we did with the previous function, but this time with some random numbers.

\begin{alignedat}{2} f(\textcolor{#4488ff}{2} + \textcolor{#ff4444}{1i}) &= (\textcolor{#4488ff}{2} + \textcolor{#ff4444}{1i})^2 + 1 &&= (\textcolor{#44cc88}{4} + \textcolor{#ffcc00}{4i}) \\ f(\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i}) &= (\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i})^2 + 1 &&= (\textcolor{#44cc88}{-7} + \textcolor{#ffcc00}{6i}) \\ f(\textcolor{#4488ff}{3} + \textcolor{#ff4444}{2i}) &= (\textcolor{#4488ff}{3} + \textcolor{#ff4444}{2i})^2 + 1 &&= (\textcolor{#44cc88}{6} + \textcolor{#ffcc00}{12i}) \\ f(\textcolor{#4488ff}{5} + \textcolor{#ff4444}{4i}) &= (\textcolor{#4488ff}{5} + \textcolor{#ff4444}{4i})^2 + 1 &&= (\textcolor{#44cc88}{10} + \textcolor{#ffcc00}{40i}) \end{alignedat}

Now we have a problem. Our output is made up of two numbers, and our Input is made up of two numbers as well. That means these count as 4 Variables. In other words, we’d need 4 dimensions to graph this equation. Since we live in a three-dimensional world, we can’t graph this output of ours in a single drawing.

Our solution is to “model” this output of ours into a single number that represents the distance from the origin.

So instead of the equation with its output looking like this:

\begin{alignedat}{2} f(\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i}) &= (\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i})^2 + 1 &&= (\textcolor{#44cc88}{-7} + \textcolor{#ffcc00}{6i}) \\ \end{alignedat}

It’ll look like this:

\begin{aligned} f(\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i}) &= (\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i})^2 + 1 \\ &= \sqrt{\textcolor{#44cc88}{-7}^2 + \textcolor{#ffcc00}{6}^2} \\ &= \textcolor{#44cc88}{\sqrt{85}} \end{aligned}

And just like that, our output is now a single number, and we have 3 variables we can graph.

Just one small adjustment: instead of writing the function like this:

$f (x + i y) = (x + i y) 2 + 1$

There’s a standard where we define $z = x + i y$ and write it like this instead:

$f (z) = z 2 + 1$

And since the output of the function is a length, we’ll add the magnitude symbol:

∣ f (z) ∣ = ∣ z 2 + 1 ∣

That’s the complete transformation of our function.

Notice now that our Imaginary axis is $y$ , not $x$ as it was in the original equation.

Also notice that our whole equation equals zero when our real part, $x$ , equals zero, and our imaginary part, $y$ , equals $i$ or $- i$ , in other words, at the point $0 + i$ and $0 - i$ .

xxyy● Roots

You’ll sometimes see it written as $j$ , particularly in engineering fields, since $i$ is reserved for current. ↩

Vector Fields

Fri, 13 Mar 2026 00:00:00 GMT

One of the most beautiful concepts in mathematics in general, and in vector calculus in particular, is vector fields. Vector fields represent many things: gravity, electromagnetic fields, and neural networks.

Play around with the tool below. Try different numbers and see what results you get. You can choose from the presets if you need some inspiration.

fieldstreamRunpresetsrotationsinksaddlesourcespiral outsine wavesgravitytwo vortices

Euler's Number

Fri, 06 Mar 2026 00:00:00 GMT

Imagine you have a coin, and I tell you, “Give me this coin, and in a year I’ll give you $100\%$ of the value you put in.” That means in a year, you’ll get another coin.

So after a year, you’ll have $1 + 1$ coins. Now, if I told you I wouldn’t give you the full $100\%$ right away, but would give you $50 %$ after 6 months, and another $50 %$ after another 6 months, how much would you have after a year?

After 6 months, you’ll have

$1 \times 1.5 = 1.5$

And after the next 6 months, you’ll have

$1.5 \times 1.5 = 2.25$

Okay, what if I said 3 months? That means you’ll get $25 %$ every 3 months until a year is up. How much will you have?

After 3 months, you’ll have $1 \times 1.25$

After 6 months, you’ll have $1\times 1.25 \times 1.25$

After 9 months, it will be $1 \times 1.25 \times 1.25 \times 1.25$

After 12 months, it will be $1 \times 1.25 \times 1.25 \times 1.25 \times 1.25$

We can see a pattern. Ultimately, the number will equal $1.25 4$

We can express $1.25$ as $1 + 1.25$ , which is $(1 + \frac{1}{4})^4$ , and that equals $2.44140625$ . Notice that our amount grows every time we calculate our interest over a longer period.

Suppose we want to do the same thing every month, every week, or every day, all the way down to every second and nanosecond, to get the largest possible value?

Our formula will be $(1 + \frac{1}{n})^n$ .

If we keep doing this forever and use a very large number— $(1 + \frac{1}{100000})^{100000}$ , for example—we’ll notice that our number approaches a specific value: $2.71828$ .

It turns out that this number is so important that we’ve given it a special symbol: $e$ .

One of the most interesting things about this number is that it has no end. As proof of this, I’d like to introduce you to Euler’s number.

$e$

The Memory Canister is Leaking

Sun, 10 Aug 2025 00:00:00 GMT

Since most of the languages we use have some form of garbage collection, very few people actually think about memory in a practical way. Who cares when you call new Foo()?

You’re right. If you’re using a language like Java or Go, you probably don’t think about it much. However, if you’re using C++, it’s a different story. Any heap allocation you make with new must be freed with delete. It’s simple, right? When I’m done with something, I delete it!

Although the concept seems simple on the surface, humans are, by nature, fallible. Because of this, Microsoft says that 70% of the security bugs in its products are caused by memory-related bugs. Most of these bugs are caused by “use after free,” which means you use a vector allocated with new, for example, after you’ve called delete on it.

This in itself proves that the new and delete approach isn’t ideal, because even when you remember to call delete, you might forget and accidentally use the memory you’ve already deleted again!

Languages with garbage collection don’t have these kinds of problems, but you pay another price: garbage collection itself.

Yes, you probably won’t have memory bugs, but garbage collection itself isn’t free. The language’s runtime takes time to identify unused resources and free them up!

Discord solved the garbage collection problem in their services (which use Go) by adjusting the settings of the garbage collector itself, but they didn’t stick with that decision and chose to use a different language because the solution wasn’t ideal.

So we have a problem. We want a language fast enough to meet our needs, but at the same time, we want to make it difficult to accidentally create vulnerabilities due to how we use memory.

RAII - Resource Acquisition Is Initialization

RAII. Resource Acquisition Is Initialization. It might be the worst name in the world, but it’s self-explanatory.

To understand what RAII is and how to use it, we need to talk in somewhat abstract terms.

If we think about what we do in most object-oriented languages, we declare variables and perform certain operations on them, whether they’re functions, methods, or whatever. But the key point is that we can’t use something unless we give it a name. The vector we’re creating could be named v, for example. How can we use something if it doesn’t exist in the program itself?

RAII is based on this idea. Every “name” in the program is responsible for freeing the memory it uses.

std::vector<int>* x = new std::vector<int>();

In this code, x is the name, and it’s responsible for freeing the vector’s memory.

What about this?

int y = 42;

There’s a difference here. The difference is that x is responsible for freeing something allocated on the heap. Anything dynamically allocated with new must remain in its own memory location so it can survive beyond its scope.

For example:

#include <vector>

void foo() {
    std::vector<int>* x = new std::vector<int>();
}

The vector’s memory won’t be freed after the function call finishes, because you’re using new.

But here:

void foo() {
    int y = 42;
}

This variable is on the stack. It’s not dynamically allocated. We didn’t use new, so its memory will be freed when the function call ends.

RAII uses this concept for heap-allocated resources.

As soon as its scope ends, for example, when the function call it’s in finishes, it’s responsible for freeing the memory associated with the resource it holds.

So, how do we use RAII in C++? The Standard Library provides this capability in the <memory> library. The basic type you can use is unique_ptr. Its name might sound a bit suspicious, like RAII, but it actually explains exactly what it does. It is a pointer, yes, but a “unique” one, distinct in that it is the only entity responsible for freeing its own resource.

For example:

#include <iostream>
#include <vector>
#include <memory>

int main() {
    std::unique_ptr<std::vector<int>> vec = std::make_unique<std::vector<int>>(5);
    // The memory is freed here.
    return 0;
}

Notice there isn’t a single new keyword in the code? Yet the vector is indeed dynamically allocated.

Want proof? Take a look at the assembly code.

main:
        push    rbp
        mov     rbp, rsp
        push    rbx
        sub     rsp, 24
        mov     DWORD PTR [rbp-20], 5
        lea     rax, [rbp-32]
        lea     rdx, [rbp-20]
        mov     rsi, rdx
        mov     rdi, rax
        call    std::__detail::_MakeUniq<std::vector<int, std::allocator<int>>>::__single_object std::make_unique<std::vector<int, std::allocator<int>>, int>(int&&) 
        mov     ebx, 0
        lea     rax, [rbp-32]
        mov     rdi, rax
        call    std::unique_ptr<std::vector<int, std::allocator<int>>, std::default_delete<std::vector<int, std::allocator<int>>>>::~unique_ptr() [complete object destructor] 
        mov     eax, ebx
        mov     rbx, QWORD PTR [rbp-8]
        leave
        ret
.LC0:
        .string “cannot create std::vector larger than max_size()”

You’ll notice that the second line uses something called std::default_delete. If we look at the Documentation, we’ll find that it says this:

The non-specialized default_delete uses delete to deallocate memory for a single object

This means that since this type uses delete, the resource is dynamically allocated!

Here, we were assuming we’re using dynamic memory on the heap. However, you can use it in a more general way. For example, a file you’ve used and want to close when you no longer need it.

Conclusion

The goal of this post is to further illustrate the concept of RAII, but there are many things I haven’t covered. Suppose I want a single user to own a single resource and need that resource to be used in multiple places?

In that case, you’d use shared_ptr. This type uses a technique called Reference Counting. Keep in mind that this technique is relatively slow!

Fun Fact: Every object you create in Python uses Reference Counting by default to determine when the object’s memory should be freed!

Hello World!

Sat, 09 Aug 2025 00:00:00 GMT

If a hammer is all you have, everything looks like a nail

This will probably be the first post on this blog.

If you ask most people to build a simple website, they’ll slowly gravitate toward React1, Angular, Vue, or one of the million other frameworks currently available.

Honestly, when I first thought about starting this blog, I turned to what I knew best: React. But then I thought about it a bit more and remembered reading about Astro. It’s designed for static sites, the kind that don’t require much interactivity.

Before I started, I had a few specific requirements:

The site needs to be fast. I’m literally not building anything amazing that would make it slow. It’s just HTML and CSS, nothing more.
Writing posts needs to be easy. If writing posts is difficult, I won’t feel motivated to write.
I need to build it quickly. I don’t want to start from scratch, but I do want to get things done!

I’m not going to explain Astro itself. If you want to learn more about it, the documentation explains it much better than I can. However, I’ll explain how Astro solves the problems I mentioned above.

Fast

If you’re building a static site, you probably don’t need JavaScript. Or, to be more precise, the client doesn’t need JavaScript.

Astro is fast because, by default, it doesn’t send any JavaScript to the client. However, Astro works as a compiler. You write everything you want in .astro files, and in the end, this is converted into a small HTML file that’s sent to the client.

For example, take a look at this code. It’s the code that fetches all the posts on the /tags page. It’s empty right now, but it’ll fill up (hopefully).

---
import BaseLayout from "$lib/layouts/base_layout.astro";
import { getCollection } from "astro:content";

const pages = await getCollection("posts");

const tagMap = new Map();

for (const page of pages) {
    for (const tag of page.data.tags) {
        if (!tagMap.has(tag)) {
            tagMap.set(tag, []);
        }
        tagMap.get(tag).push(page);
    }
}

const uniqueTags = [...tagMap.keys()];
---

<BaseLayout>
    <h1>Tags</h1>
    {
        uniqueTags.map((tag) => (
            <div>
                <h2 id={tag}>
                    <span>#{tag}</span>
                </h2>
                <ul>
                    {tagMap.get(tag).map((post) => (
                        <li>
                            <a
                                href={`/${post.data.pubDate.toISOString().substring(0, 10)}/${post.id}`}
                            >
                                <span>
                                    {post.data.pubDate
                                        .toISOString()
                                        .substring(0, 10)}
                                </span>
                                <span>-</span>
                                <span>{post.data.title}</span>
                            </a>
                        </li>
                    ))}
                </ul>
            </div>
        ))
    }
</BaseLayout>

What is this? Are you kidding me?! This is JavaScript! And what’s this, too? Two nested for loops!

This is $O(n \times t)$ !2 How could this possibly be fast?

You’re right… this isn’t exactly efficient… if it were executed at runtime. The idea is that Astro sees this code and converts everything to static HTML. Ultimately, it compiles the JavaScript you write and converts it to HTML & CSS. This way, Astro preserves the DX by letting you write in a scripting language, while at the same time preventing the client from sending it things it doesn’t need!

This contrasts with the concept behind popular frontend frameworks, where a single HTML page is dynamically updated by JavaScript (these are Single-Page Applications).

Don’t believe me? Check the Network tab in Chrome DevTools. There aren’t even any JavaScript resources.

Writing Posts Made Easy

One of the easiest languages you can use and learn in literally an hour is Markdown. It’s also one of the least known languages in terms of syntax, I don’t know why. It feels like everyone collectively decided decided to write their README files using AI.

Most of the time, you’ll write your content in Markdown in Astro, and that Markdown will eventually be converted to HTML so your browser can read it.

Why not just write in HTML from the start? You can do that, sure, but you’re basically punishing yourself. If given the choice, would you want to write this:

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <title></title>
    </head>
    <body>
        <h1>Hello, World!</h1>
    </body>
</html>

Or this?

# Hello, World!

Quick DX

I’m not a fan of building UIs. For me, it’s the most tedious part of writing any software. So I use tools that make it easier for me whenever I get the chance, and the first one I usually turn to is Tailwind.

Another thing I might use is any component library that uses Tailwind. If I were using React or Next.js, I’d probably choose ShadCn, but I had a specific vision for how the blog would look, and unfortunately, I couldn’t find anything that matched exactly what I wanted and didn’t use JavaScript, so I had to write my own components from scratch (yikes).

It wasn’t too hard, though, because Astro also lets you create your own components. Any .astro file is considered a component from Astro’s perspective.

For example:

---
const { post } = Astro.props;
---

<div class="w-full">
    <div
        class="flex flex-wrap gap-x-3 divide-dotted text-xl text-wrap opacity-70"
    >
        <span class="text-wrap">
            {post.data.pubDate.toISOString().substring(0, 10)}
        </span>
        {
            post.data.tags.map((t) => (
                <>
                    <span> • </span>

                    <a href={`/tags#${t}`}>
                        <span>#{t}</span>
                    </a>
                </>
            ))
        }
    </div>
    <h1 class="mb-0">
        <a
            href={`/${post.data.pubDate.toISOString().substring(0, 10)}/${post.id}`}
        >
            {post.data.title}
        </a>
    </h1>
    <span class="italic">{post.data.subtitle}</span>
</div>

This is the code that displays the Title, Subtitle, Date, and Tags for each post. The component takes a Post prop and renders this information based on each post.

You can use it like this:

---
import { getCollection } from "astro:content";
import PostHeader from "./post-header.astro";
const allPosts = await getCollection("posts");
---

<div class="flex h-full w-full flex-col gap-y-12">
    {
        allPosts
            .sort((a, b) => b.data.pubDate.getTime() - a.data.pubDate.getTime())
            .map((post) => (
                <div class="flex flex-col">{<PostHeader post={post} />}</div>
            ))
    }
</div>

You use it just like any other component you’ve used in your life (most likely).

Conclusion

Astro isn’t the only Static Site Generator. There’s also Jekyll, 11ty, Hugo, and others. Of course, I haven’t used them all, and I might very well end up liking an SSG other than Astro, but it’s hard to imagine a developer experience (DX) easier than Astro’s.

I hope I’ve encouraged you to use Astro for a project, and if you do use it because of this post, send me a link!

React is a library, not a framework… I know… I know. ↩
The “O” looks cool, right? These are Astro plugins that it supports: remark-math and rehype-katex. Astro also supports syntax highlighting for code using Shiki and Prism. ↩

Shenawy's Blog

Why Neovim in the Age of Agentic Coding?

Introduction

How Neovim and I met

What is Neovim

Practical Examples

Any Agent Could Do This…

Conclusion

Enter the Arena

Stack Based Allocations

Heap Based Allocations

Manual Memory Management: Problems

300,000 Rats

Lifetimes

The Arena Allocator

The Arena Struct

Arena Allocation

CPU Alignment

Arena Allocation: Continued

Reset & Free

Arena Usage

Benchmark: Arena vs malloc

Credits

Imaginary Numbers Are Real

The Evolution of Numbers

The Equation

Imaginary Numbers

The Complex Plane

Complex Numbers

Operations on Complex Numbers

Addition

Subtraction

Multiplication

The Elephant in the Room

Footnotes

Vector Fields

Euler's Number

ee

The Memory Canister is Leaking

RAII - Resource Acquisition Is Initialization

Conclusion

Hello World!

Fast

Writing Posts Made Easy

Quick DX

Conclusion

Footnotes

$e$