Getting the Memory Back

max@bonnef.in (Max Bonnefin) — Thu, 22 Oct 2026 00:00:00 +0000

Almost every line of code I’ve written in my career has run on top of a garbage collector. Java, TypeScript, Python, Go. Languages where memory is something the runtime worries about so I don’t have to, and where for years I was happy to let it. My general day to day backend work doesn’t punish me for not knowing where my bytes live.

I read a book on data-oriented design a few years ago and it stuck with me, but I never had a project where putting it into practice made sense. So I set about building a small game engine as an excuse to manage my own memory for once, and picked Odin to do it in because it stays out of the way while you work at that level. The language is the vehicle here, not the destination. What I actually wanted was to find out what all those years of letting the runtime decide had stopped me noticing.

The engine itself is just the test rig. It’s a 2D thing with SDL3 for the window and input, a software renderer and a shadow-casting mechanic I’m still playing around with. It is currently unfinished and may well stay that way as it’s just a prototype.

Why not Go Link to heading

Go is probably my favourite language at the moment and the obvious place to start from, so it’s the one worth measuring against. I like it a lot, reach for it constantly, and I’d defend it in most of the contexts I use it. This isn’t a breakup.

The whole exercise was about owning something Go deliberately withholds: control over when and where memory moves. Go’s garbage collector is a feature almost everywhere else, a decision the language makes so I don’t have to, and for most use cases I am glad to let it. In a frame budget of 16 milliseconds I wanted to make that decision myself for once. This is a preference, not a horror story. I didn’t profile a stuttering collector and storm off. You can actually configure and customise the Go GC pretty extensively¹ but I just wanted the allocation to be mine, and Go is designed so that it mostly isn’t.

There’s a smaller thing too, the kind of papercut you only notice writing tight code all day. Odin has a ternary and Go doesn’t. Switching level on a door is one line:

state.level = state.level == .Hub ? .World : .Hub

Go has no ternary at all, so the same thing becomes a multi-line if/else assigning to a variable, every time, forever. It’s a tiny ergonomic win and I’m not going to pretend it’s the reason I chose the language. It makes me wince every time I write the Go version, though. Being able to stop fighting the grammar for something this simple is just pleasant.

The honest counterweight: if I were starting a project with junior engineers on the team, I’d pick Go without hesitating. Its refusal to let you manage memory is exactly what you want when you can’t assume everyone has internalised the consequences of getting it wrong. The things that make Go a slightly blunt instrument for a game loop are the same things that make it a safe one for a team.

Why not C/C++ Link to heading

Game code closer to the metal usually means C++. Decades of accumulated features and compile times that climb for little benefit have made it entirely unappealing to me.

A better option is the OG C. I like C in the way you like an old tool that has clearly earned its place. Philosophically it’s hard to argue with; the C spec is still the gold standard of language specs. I’ve written a modest amount of C in my life, only ever hobby stuff, mainly homebrew Game Boy games with GBDK, but writing it in 2026 feels archaic.

Header files that make you declare everything twice. Strings that are a pointer and a prayer, null-terminated and happy to walk off the end of their buffer. No defer, so cleanup is a manual discipline you get wrong under pressure. A preprocessor doing text substitution underneath the language rather than anything the compiler understands. I know there is “modern C” that makes it more usable now, but the foundations haven’t moved.

Odin keeps the part of C I actually wanted (direct memory, no runtime between me and the machine) and drops the 1970s ergonomics. Proper slices and strings that know their own length. defer built in. No separate declaration ritual. No single feature made me sit up. It was the accumulated relief of a language that does the obvious thing without ceremony.

Owning the memory Link to heading

The thing managed languages had quietly taken from me was the habit of thinking about memory at all. The first lesson of doing it by hand was how little of it you actually need to do if you plan the lifetimes up front. Everything in the engine comes back to one decision made at startup: the platform layer reserves two large blocks of memory and hands them to the game, and nothing else allocates from the operating system during normal play.

permanent, permanent_err := virtual.reserve_and_commit(64 * 1024 * 1024)
transient, transient_err := virtual.reserve_and_commit(64 * 1024 * 1024)

memory := game.Memory {
 permanent = permanent,
 transient = transient,
 read_entire_file = platform_read_entire_file,
}

Sixty-four megabytes each. The game’s entire persistent state is a single struct living at the top of the permanent block, and on the first frame the game takes that memory and reinterprets it as its State:

state := cast(^State)raw_data(memory.permanent)

No allocation. The bytes already exist. The game just decides what they mean. That one line did more to break my managed-language instincts than anything else in the project. In Go I’d reach for a constructor and let the runtime find room for the object. Here the room is already there, I’m simply pointing a type at it, and the distinction between “make me a thing” and “treat these bytes as a thing” is suddenly load-bearing.

Whatever’s left of the permanent block becomes a bump allocator for everything loaded once and kept. The allocator is about thirty lines, and the part that matters is tiny:

case .Alloc, .Alloc_Non_Zeroed:
 aligned := (arena.used + alignment - 1) & ~(alignment - 1)
 if aligned + size > len(arena.data) {
 return nil, .Out_Of_Memory
 }
 result := arena.data[aligned:aligned + size]
 arena.used = aligned + size

Move a cursor forward, hand back the slice. Freeing a single allocation does nothing on purpose; the only way to reclaim space is to reset the whole arena at once. That sounds reckless until you notice it maps exactly onto how a game actually uses memory. Assets loaded for a level live as long as the level. When you’re done, you don’t free them one by one, you throw the whole region away and start again. The allocation strategy and the lifetime of the data are the same shape.

The game loop allocates nothing. Every frame reads input, mutates the State blob in place, and writes pixels into a buffer that was created once. A garbage-collected language doesn’t stop you from working this way, but it spends a lot of effort inviting you not to. Odin assumes you’d rather know.

Data-oriented design, honestly Link to heading

The ideas I’d been sitting on came from Richard Fabian’s book on data-oriented design. There’s a free abridged version online. I read it a few years back, nodded along, and then went back to writing the same object-heavy code I always had, because nothing in my day job rewarded doing otherwise. The core idea is that you design around how data is laid out and accessed, because the cache is the thing that actually determines whether your program is fast, not how elegant your object model looks.

I’ll be straight about how far I took it. Odin has first-class structure-of-arrays support, the #soa keyword that transposes an array of structs into a struct of arrays for better cache behaviour.² I didn’t use it. I wasn’t actually aware of this language feature at the time but I don’t think the engine is pushing enough entities for that transformation to earn its place yet.

What I did take is the mindset, and it shows up in the layout. The shadow system is a fixed array sized to the map, not a dynamic list that grows and shrinks:

shadows: [MAP_ROWS * MAP_COLS]Convex,
shadow_polys: [MAP_ROWS * MAP_COLS]Shadow_Poly,
shadow_count: int,

There are 32 by 8 tiles, so the worst case is 256 shadow-casting shapes, so I reserve 256 and track how many are live with a count. No allocation when the light moves, no resizing, no pointer-chasing through a linked structure. The collision code works the same way, projecting polygon points onto candidate axes in tight loops over contiguous arrays. The data sits where the next access expects it to be.

The habit the book was trying to teach me, and that only stuck once I actually built something, is to think about a piece of data’s shape and lifetime before I think about its behaviour. Odin makes that the path of least resistance. Go actively hides it from you, which is usually a kindness and occasionally the exact thing you’re trying to escape.

Hot reload falls out of the architecture Link to heading

Owning the memory bought me something I didn’t plan for. The game logic compiles to a shared library and the main loop watches it for changes. Rebuild while the program is running and it loads the new code mid-frame, with the player still walking around, their position intact. I can change how jumping feels, rebuild and watch the character respond differently mid-leap.

State survives the swap because state was never in the library. The code lives in the shared object; the data lives in those two memory blocks the platform owns, and they’re handed straight back into the fresh code on the next frame. This is the Handmade Hero architecture and I invented none of it.³ The point worth making is that it falls out of the memory decision for free. Once the data lives outside the code, hot reload stops being a trick you bolt on and becomes a thing that simply works. In a managed language the state would be tangled up in objects the runtime owns, and this would be far harder to pull off. Doing the memory myself made it almost incidental.

What annoys me Link to heading

A post that’s all praise is just a sales pitch, so here’s the other side, kept proportional to how much it actually bothers me, which is not much.

Odin dropped the increment and decrement operators.⁴ No i++. You write i += 1, which is three extra keystrokes and a flicker of irritation every time my fingers reach for the shorter form out of twenty years of habit. That’s the complaint. It’s a small language with a small standard library and a small community, and when something isn’t in the vendor collection you’re writing it yourself or binding to C.

The one corner where that thinness actually slowed me down was core:testing. I lean on tests, so I noticed its edges quickly. The matchers are minimal, really just expect and a couple of variants, so you hand-write the failure message every time rather than getting a “wanted X, got Y” for free. There’s no setup or teardown hook, so shared fixtures get rebuilt by hand in each test. No built-in coverage report. The runner is bare. There’s no mocking or spy machinery either, which is a deliberate choice I mostly agree with; a language without pervasive runtime reflection is a language where that machinery can’t quietly take over your test suite. I say mostly, because I don’t think reflection is the absolute devil, and once in a while I did miss being able to stub a dependency without restructuring the code to allow it. None of this stopped me writing the tests. It just meant doing a bit more of the scaffolding myself, which, given everything else about the language, I should probably have expected.

I should be clear about the limits of my opinion and experience here. So far I have only used Odin for hobby projects. I have no idea what it’s like to hire for, to onboard a team onto, or to run in production under real load, and I’m not going to pretend the view from a handful of weekend projects tells me any of that. What I can say is that for one person building a game engine for the pleasure of it, the tooling has been good enough, which is quite a high compliment.

Where this leaves me Link to heading

Odin hasn’t replaced Go for me and I never wanted it to. The two solve different problems and I’ll keep using both. What the experiment actually gave me wasn’t a new favourite language, it was the memory back. After a career of letting the runtime decide where my bytes live, spending a few months deciding for myself has changed how I read every program, managed or not. Odin was the right vehicle for that: close enough to the metal to force the lessons, modern enough not to make me suffer for them. The nearest alternative is still behind a closed beta, so we’ll see if this holds once the long-awaited Jai reaches public release.

The engine will likely never ship a finished game, which was never the goal. I’ve learned more about how computers actually spend their time from building it than from any amount of backend work, which tells you something about what you give up when the runtime handles everything for you.

The Go GC guide covers the knobs. GOGC sets the target heap growth between collections (default 100, meaning the heap can double before a cycle), GOGC=off disables the collector entirely, and GOMEMLIMIT (Go 1.19+) sets a soft memory ceiling the runtime tries to stay under. You can change the percentage at runtime with runtime/debug.SetGCPercent. Plenty of control, just not control over individual allocations. ↩︎
Odin stores #soa arrays as a struct of parallel arrays internally while letting you index them as if they were an ordinary array of structs. See the #soa section of the language overview, and the forum thread for the tradeoffs it makes under the hood. ↩︎
Handmade Hero is Casey Muratori’s series building a complete game from scratch in C with no libraries. The platform-owns-the-memory split and the hot-reloadable game DLL both come from his early episodes. ↩︎
The reasoning is in the Odin FAQ: ++ and -- look simple but depend on evaluation order, which can lead to bugs. i += 1 is slightly longer but unambiguous. I agree with the principle. ↩︎

Game-Engine on Max Bonnefin