Resources

Rationale

This is a curated list of learning resources because I have been asked "where did you learn X" too many times. It's also as a reference for me, so I can re-visit some of the resources in here.

I am not affiliated with any of the links/resources, and I either personally use them, used them, or would recommend them to a friend.

I link/refer to Krypton a few times, Krypton is the compiler I am working on currently, it's in closed beta (such a JBlow move, IK lol), If you want access to the repo, just ask me on discord or email me at <contact@kyren.codes>.

Also gitea doesn't support footnotes apparently, when u see [^N], go to the bottom to see the footnote.

Recommended order

This expects you to know at least one programming language, if u don't, check boot.dev.

Resources inside a section try to be ordered from which one to go through first, but they are fairly unordered, so go in whatever order you wish.

After finishing the C section, I'd recommend mixing these 3 sections:

• Get good at using C
• How to ACTUALLY manage memory (it's easy!)
• If you are interested in gamedev, then that section
• If you are interested in compilers, then that seection

I also recommend reading this entire page first, and only then starting to go through the resources, that way, you have an overview of what's coming up and what order to watch stuff.

Learn C

The 7 "pre" episodes of Handmade Hero by Casey Muratori ("Intro to C on Windows") - it's a good but incomplete, quick overview of the C language and how memory actually works, but you won't be able to jump into programming in C with it.

Boot.dev's C Learn Memory management in C course - it's a good course about the basics of C and it shows different techniques for how garbage collectors are implemented. But it is NOT a good example of how I'd recommend you manage memory in general (see later sections for that).

Get good at using C

Casey Muratori's BSC 2025 talk - Unlearn OOP, or more precisely, "compile time hierarchies of encapsulation that match the domain level" (aka inheritance == bad).

Handmade Hero by Casey Muratori (first 30-60 episodes) - teaches you to make a game from scratch. And actually from scratch, the only thing he uses are OS APIs (which u can't get around[^1]). Even if you are not planning to be a game developer, this will teach you a ton, and I highly recommend watching it, if you are a game developer, I recommend continuing even after episode 60 (but prioritize other resources first!).

Vjekoslav's BSC 2025 talk - shows alot of techniques on how to use C in a modern way, I found it extremely helpful and practical for architecting my compiler codebase. It shows examples for writing your own standard library (base layer), arenas (see memory management section), ditching C-style strings and more.

Semantic Compression by Casey Muratori teaches how to do the "daily plumming" of programmers, like extracting and reusing code on a "when needed" rather than premature abstraction, this inspired the "Semantic compression over premature abstraction" in the Zen of Krypton.

Ryan Fleury's Realtime debugger architecture BSC 2025 talk - harder to digest, especially if you are new to this like I was when watching it (I would re-watch this again in the future), you may skip this. It goes over how to architect a debugger UI, which is especially hard to do, considering cases like displaying nested structs, large arrays, strings, image-data etc.

Dennis Gustafsson's Parallelizing the physics solver BSC 2025 talk - not really about C, but shows interesting ways to parallelize things and avoiding mutex contention, would recommend watching this, but not strictly necessary.

Andrew Reece's Assuming as much as possible BSC 2025 talk - a ton of things there went over my head, and I only watched the first 30m of it, but it's EXTREMELY good, and that's where I got "Assume as much as possible" and "Bits are high level" in the Zen of Krypton. I'd recommend either skipping it, or rewatching it multiple times, until you fully digest it (and probably watch Ryan's Fleury BSC talk first).

How to ACTUALLY manage memory (it's easy!)

First, realize you do not know how to actually manager memory, so throw away all the misconceptions u have been taught.

Enter the Arena by Ryan Fleury teaches about arenas, the "magical" allocator (actually it's dead simple and not magical). Goes over arenas in general, permanent areans, transient (temporary) arenas, and scratch arenas.

Vjekoslav's BSC 2025 talk - linking this talk again because it shows more practically how to use arenas, scratch arenas, transient arenas, it goes over grouping lifetimes into arenas for an actual application.

Ryan's Fleury blog about arenas - great intro to arenas, similar to the talk he gave, I'd recommend both, but if u r short on time (or priortize other resources here), you can choose one, and delay/skip the other (personally I went with the talk, and only read part of the blog post).

Podcast with Ryan Fleury - it goes over arenas, specifically what they are, and also about how memory works and a bit about virtual space.

For arena implementations, see Krypton by me, or the Rad Debugger (by Ryan Fleury)

Becoming an N+2 programmer by Casey Muratori, from HMM explains that thinking about individual objects/allocations is REALLY hard, and that grouping allocations makes managing memory REALLY easy. And what's a better way of grouping allocations then arenas (one arena per group of objects/lifetimes).

Also a bit of an explanation from me, because all these talks do mention this, but gloss over it: Computers have physical and virtual memory.

If you are running on a 64-bit machine, it means pointers are 64-bit, but u don't actually need 2^64 bytes. Usually, only the 48 bottom bits are used, which total to 256TB of RAM[^2] (note, only the top 8 bits are unused, and they are reserved[^3]) This gives you 256TB of "virtual address space".

And the CPU has special tables that translate virtual memory addresses into physical addresses "automatically", so you don't have to worry about it.

Operating systems work with "pages" (usually 4kb), and allow you to either "commit" or "reserve" pages. Pages are the smallest unit of memory you can ask from the operating system. Reserving pages tells the OS to mark them as "used", so if you ask it for more memory, it would not return a "reserved" page. Committing pages actually asks the OS "hey, give me physical memory to back this page".

Physical memory is (almost) always segmented, but from your program's point of view, virtual address are continuous, even if the backing physical memory of pages is scattered.

Knowing this, arenas are usually implemented by reserving a large chunk of virtual space, but only committing it as needed. This allows for more efficiency in growing arenas, compared to using malloc (which is a 6k lines wrapper around committing/reserving OS virtual memory).

If you have used C++ (and maybe Rust), you'd know that you can't keep pointers from a list after you append to the list, why? Because the list (vector) might need to grow, which means, allocating a new chunk of memory, copying all the elements, freeing the old chunk, this is known as "unstable pointers" (bcz u can't rely on them).

Now, what if instead, we reserved a huge chunk, say 64GB of virtual address space, now when the list needs to grow, we don't need to re-allocate, and copy, which is VERY expensive, we only need to tell the OS to commit more pages. Obviously in a real application, unless you know the list is REALLY large, you are probably fine reserving a smaller amount, like 64MB.

Game Development

TODO: this took me very long to make, will add this later (remind me if I forgot!)

But tldr; handmade hero, all of it, then u should be able to learn on your own.

Also the BSC 2025 talk by Ginger Bill for math, and Freya Holmer's "math for gamedev" series.

Compiler and Language design

TODO: this took me very long to make, will add this later (remind me if I forgot!)

Crafting interpreters for the basics of tokenizing and parsing, not more than that, the book later diverges into what I'd call "bad OOP" (in part 1), and part 2 is mostly about virtual machines, I only read the start of part 2, I'd only recommend it if you are making a VM for your language.

Simple but powerful Pratt's Parsing for how to properly deal with precedence when parsing expressions, there is also a "Core Dumped" video covering it on youtube, but I find the blog to be better.

Jonathan Blow talks, specifically Jai ones where he shows features like compile time and AST injection.

Programming language documentation, specifically the zig docs, odin docs, cakelisp, Nim, cppfront and probably some more that I forgot.

Resources (unordered)

• ALL Better software conference talks, they are all great.
• Handmade Hero by Casey Muratori AT LEAST the first 60 episodes
• Semantic compression by Casey Muratori
• On bad advice
• John Carmack on Inlining code
• Ryan Fleury blogs
• Casey Muratori's Blogs

[^1] Unless u write your own OS, but even then, you'd be interfacing with hardware. and I assume you are not going to manufacture your own CPU.
[^2] Certain CPUs use 52-bit or 56-bit, because of some super computers hitting the 256TB limit (bruh)
[^3] Some arm CPUs have TBI (top bits ignore), to allow storing metadata in the top 8 bits of a pointer