I like the part about memory management. Arenas are so simple. In the (toy) web server I'm writing I initially also started with arenas. However I quickly realized that I don't actually need to grow and shrink memory at all. Currently I'm simply allocating the memory I need up front then slice it up into pieces for every module. When we're programming, we often pretend like we could be needing arbitrary amounts of me…
Right, I'm always annoyed when people talk about how std::vector has terrible performance (especially for games), which it certainly does if you just start with an empty vector with no memory reserved and append a few thousand items. But it is very frequently possible to find the actual maximum you will need, allocate that upfront, and everything's great.
But when I realized that if I wouldn't allocate a large enough backing array (capacity) then memory would grow by n+(n+1)+(n+2)... every time I allocate on the arena during a request.
Now you're right that this is not necessarily a problem. But this is a side project that I just write in order to learn and explore stuff.
So I thought I would need to figure out a static capacity and was thinking about how to go about this. Then I realized I don't need a data structure that grows, but only a slice of a static memory region, which then means I don't need an arena (which can arbitrarily grow) in the first place.
Now I'm exploring all kinds of things that a web server does and where I would normally use a dynamically growable data structure. Like parsing JSON, form parameters, HTTP headers etc. And I can find natural or self imposed limits for all of those things.
For me, the most interesting thing about this isn't even performance. It's the mere fact that you _can_ figure out and design those limits. And the resulting code doesn't become complicated, but looks much simpler than I would have guessed. I really like the exactness of it all and how it changes the way I think about these things.