DEV Community: Brandon Harrell

Unemployed proejct #1: KV Store concepts and WAL

Brandon Harrell — Tue, 23 Jun 2026 16:32:23 +0000

Introduction to database design

So as we start looking into the internal of a database. We must ask what a database actually is? According to Amazon AWS website this is the description:

A database is an electronically stored, systematic collection of data. It can contain any type of data, including words, numbers, images, videos, and files. You can use software called a database management system (DBMS) to store, retrieve, and edit data. In computer systems, the word _database_ can also refer to any DBMS, to the database system, or to an application associated with the database.

That is somewhat accurate. But the next question becomes:

"If we are storing data, how do we represent it?"

This is of course through something we've all used called files. Essentially a database just represents files on a disk. And a database retrieves these files on disk through a pointer to the location on disk or an index. This also happens in file systems, as we have file pointers to locations on disk. But a database is very organized way of doing this.

So why do I use term KV store? Well databases have a long history and have gone through many different technological changes. One of the key changes was the change for hierarchical databases to relational databases. The history of that is beyond the scope of this blog entry. But we started to see the dominance of relational database systems like Oracle, SQL Server, Postgres, and MySQL in the industry. These database are fairly complex, typically have a storage engine and a query engine built on top of them. As long with other design considerations like being ACID which gives consistency and durability gurantees. In the late 2000s a certain class of databases emerged called NoSQL databases. These addressed issues with relational databases (again won't get into them here). But they were even sub-divided into categories like Document databases, Graph databases, and more importantly Key/Value stores

I would say in terms of databases KV stores are the most foundational. We just take a key and point to a value. Popular KV stores are Redis, RocksDB, LevelDB, etc. They can often serve as caching layers for distributed systems, or a place to store information about clusters. They also allow you to play around a bit with the shape of data, as data modeling just require a big composite key.

As an educational exercise (as this clearly is). Its a really good target without being too ambitious. Its a solid foundation at the very least.

Now lets go over the architecture of a KV store

KV Store high level overview

When you store data into a database. Your storage engine will take your data, segement your infomation into chunks and then eventually flush it to the file system. Writes to disk are expensive, so the sake of efficiency your data is kept in memory for for a certain amount of time. But since memory is volatile, if your program crashes before this happens all data can be post or partially be persisted to disk which can cause data corruption.

KV Stores often use something called Log Structred Merge Trees (as opposed to B-trees). This consist of 3 parts

Memtable
String Sorted Table
Write Ahead Log

The Memtable is often where your data is sent. This holds your data in memory, and is usually backed by some tree like data structures. For Memtables you need a balanced tree. It is common to use a Red-Black Tree or a Skiplist. The reason being is because these data structures make writes less expensive and can be good for concurrent writes. B-trees in traditional relational database systems tend to be better for reads, but more expensive for writes

Memtables often persist to disk and this is where a String Sorted Table (henceforth SSTable) comes into play. These will be chunks of your data sorted to disk.

Write Ahead Logs are for durability. It is basically a copy or memo of your database. When there is a crash its a bit of a backup of your database that can be recovered in the case of a crash. WAL is the most basic part of a KV store. So that is what we are beginning with

WAL log and how it works

The build blocks of a WAL is a checksum. This will ensure that the file is intact when read from disk. If the checksum is incorrect, then this will likely be a file corruption problem of a bug reading from disk. WAL usually have a message format, and the checksum is inside of what is known as its header. For my code I have an incredibly simple WAL format. Its probably way too simple, but I hope to expand on it in this blog.

My header is 7 bytes long. Below is a table of the layout

Bytes	data
0-4	checksum data
5-6	header length.

You'll see more feature rich WALs have things like LSN or SNs (sequence numbers) and other metadata but this is fine for now.

Each WAL chunk is about 64KB. The rest of the data is they key_length, key, value_length, and value. And this makes up the entirity of our payload.

Wrapping up and next steps

Ok I gave a huge theoretical overview of WALs. Next Blog entry I'll actually dig into writing some code. What I didn't want to do is just start with code, and there is nothing to follow along with.

Code is here: https://github.com/brharrelldev/walbash_db/tree/main/walbash-rust

And you can always email me at: ministerofdefense1979@gmail.com

Happy coding!

Employed project. KV Store from scratch in Rust

Brandon Harrell — Tue, 23 Jun 2026 16:30:43 +0000

Introduction and motivations

Hello my name is Brandon, thought I'm known through most of my social media as Minister Of Defense. One day I a more casual blog, I'll give some lore behind the name. Anyway I just want to say I've been a software professional for about 25 years. I've held a number of different roles and titles. But I think one of my most transformative titles I had was a data engineer.

In 2013 I worked a very long term contract with Comcast. And there I worked for their cable modem provisioning team. I won't go into too many details. But I found myself dealing with a lot of data realated problems. And I found working with data to be really exciting.

At the time the NoSQL craze was really hitting the industry. And in that I really started to dig deeper into core database fundamentals. I started understanding tradeoffs in data, consistency gurantees, and the shape of data. I was also dealing with distributed state across clusters. And these became interesting problems to solve.

This started my obsession with database foundations and internals. It started as a curiosity and it became something I wanted to do.

Why did it take you 13 years?

So I said I start my obsession with database internals 13 years ago. But why did it take 13 years to want to build one? 2 words. Skill issue.

The first problem was the lack of a programming language. At the time I was working in a strong Java shop, and why it was a more data oriented team (we did a lot of Hadoop and Elastic search a the time), it was still firmly an enterprise position. I also did a lot of Python during this time, and Python wasn't powerful enough to really build a database. At least not the one I wanted to build.

I wanted to re-learn C++ since most of my education was in C++. But it felt overwhelming. Eventually I ran into things like LevelDB and RocksDB. I tried to study these code bases, but it felt like I really couldn't understand what was going on.

Eventually over the years I started to understand things like B+ trees vs Skiplist/LSM trees. But it was a slow process, and I never really knew where to get started.

In 2016 I would leave Comcast, and I would work for a government contractor. This lead me to using Go in the backdoor. And as many known I've built a Go career from there. Go gave me a little more confidence in building a database. But I wanted to understand it from first principles. I wanted to understand memory, building memory maps, etc. I knew I still needed to learn a lower level language to do so.

Enter Rust, then Zig, then Rust again

Now the plot thickens. During my years as a software engineer I was never good with side projects. I felt that a side project had to really become a business. And I'm not going to lie, I'm not very project focused. I'm a tech guy, and the stuff I was interested in building was lower level stuff. Things I didn't do on my day job, and I felt was too wide of a skill gap. However, Go gave me this new sense of confidence move forward and try lower level things.

However something was also fascinating about Rust. So I tried to used it. And failed. And tried again and failed. I started to realize that this language is very hard to get productive in. You need to study borrow checker rules and semantics. Its a language that didn't lend itself to experimentation.

So let's fast forward to 2024, I was laid off for the first time in probably over a decade. And I found myself with time on my hand. I knew that I no longer wanted to build side projects just to start a business. I just wanted to build cool software. I learned about the Primegen's channel at the time, and he talked about Zig. He spoke of Zig as a simple language that didn't get in your way, but was also lower level and powerful. And I had to try it. I fell in love. And for the first time, I attempted to write a database in Zig.

I didn't get far, and eventually I went back to work. And once that happened I abandoned my side project.

Fast forward to September 2025, after frustration with AI. I decided to write a game in Zig. I decided to use AI as a tutor, and not as something that just hands me answer. I would write the code myself, and AI would be an advisor to teach me game dev. And its been working out.

So it gave me the confidence to also create a database in Zig. Yes Zig. I started writing a dabase in Zig, and even completed a write-ahead log (WAL). Again, AI not writing any code, just advising me, teaching my concepts, and me struggling through the implementation and code.

So you may be asking, where is the "and Rust again part"? Glad you asked. As of June 2026, I find myself unemployed yet again. And I want to get back into infrastructure. So as a career signaling initiative, I decided to write my KV store in Rust.

TLDR bro. What are your plans

My plan is to make this.

Basic functionality

Write Ahead Log implementation
Memtable and SSTable
Bloom filter/range queries

Polish and UI

write basic CLI using clap
maybe a tui to visualize data
debugging and diagnostic tool chain
integrated performance monitoring

Neuromorphic modeling

z-curve order indexing
neuromorphic memory representation

stretch goal

consensus algorithm (RAFT)
secret feature I don't want to disclose
create API and kubernetes operator

Currently I am in a job search, and I am building a game in Zig from scratch. So lots of things to work on. This KV store work will tie into my game, as I have some ambitious ideas around it. So this is important to my overall mission.

Code for the project is here: https://github.com/brharrelldev/walbash_db/tree/main/walbash-rust

If you have any questions feel free to email me at: ministerofdefense1979@gmail.com

Neuromorphic KV store in Zig

Brandon Harrell — Sun, 01 Feb 2026 20:07:54 +0000

Introduction

Hello in 2026 I decided to start a new project in Zig. It's actually a neuromorphic DB engine called Walbash DB. The name walbash is a play on Wabash. A neighborhood where I grew up in KC

Walbash is just a play on that. WAL-Bash. WAL (Write Ahead Log) and Bash (bourne again shell). But honestly its just a silly name. Moving on

I'm building a game, but I also want an excuse to do something with neuromorphic computing. I have a design concept using neuromorphic computing with my game that I may reveal later. But this database is to store synaptic weights to be used for a neuromorphic engine I'm working on

Why Zig

I'm not a smart guy. And what I mean by that is that I do like a lot of cognitive load. I've found in my engineering career that I prefer languages that give me maximum control while be cognitively straightforward. I remember trying to learn Scala and Rust over the years. These languages frontload you with features and makes it difficult to be productive

I work with Go professionally. But I wanted something low level because that's my interest. So Zig fit the bill. Odin exists too, but it syntatically is too similar to Go. Its hard for me to not think I'm not just writing in Go. Zig introduces a different muscle memory for me.

Why build your own database?

Because I've always wanted to. Just never had a good reason. And its really hard. Not just to execute, but to learn all the supporting theory. I've read books on databases and found myself just copy and pasting the code without understanding it. Which robs me of learning the "why".

AI has been a good way to research and learn on my own time with my own style. So AI is more of a research partner

Why is this not being generated with AI?

This is important. First I think the performance I'm going for isn't going to be done well by AI. It's too low level and niche for me to trust its output. Secondly I don't want to robbed of the joy or learn and implementing it myself. If my repo you will notice markdown files, but they are explicitly told not to generate code. This is very important for me

What makes your DB unique?

Absolutely nothing. It's just a learning exercise. I don't expect competitive features. This is also for my personal project. Not really meant to be used by anyone else. I'm blogging this because I just want to share my journey. It also keeps me on track.

How often should we expect updates?

Depending on progress. I'm starting the DB now so progress is fast. As I get into Memtables and testing, I expect things to slow down a lot. DB from scratch is hard. I anticipate a lot of testing. I'm also splitting time between my game and my neuromoprhic engine. And this is all being done part time.

Following my passion #2: position vector and learning more Zig

Brandon Harrell — Thu, 01 Jan 2026 03:20:29 +0000

Introduction

Ok, so actually doing some coding for my project on a work night. And boy did I have a busy day at work. I'm in crunch time and I had to debug this really annoying issue with Kafka. Thats a blog for another time lol

Ok moving the square

So yesterday I made a bootstrap Raylib project and it was just drawing a square to the screen. Today the goal was to make the square move. Which I did accomplish

How did I do it?

Well I'm going to admit I'm cheating a little. I'm not entirely new to game development. Well at least this isn't my first attempt. I once tried to write a game in C++ in 2024 during a layoff (layoff didn't last long, and I dropped the project once I got a job). So I do know about position vectors to some extent. But since I'm fairly new to Zig this was going to be an interesting challenge

Interesting stuff about Zig

So Zig reminds me a lot of Go, but there are obviously some big differences. I tried to introduce a little code structure to my project by keeping a Player struct.

const Player = struct{
  .x: usize,
  .y: usize,
  .width: usize,
  .height: usize,
}

This is just to define the position and size of our square on the screen. You'll immediately see and issue if you've worked with Raylib, but I'll get into that.

Like Go or Rust you can also attach methods to your structs. However unlike Go, your constructor goes inside your struct. In Go you typically have your construct to create and initialize the struct. Which is happening here. But in Go you don't usually have the construct as a function receiver.

By convention (pretty sure this isn't imposed by the language), you construct your object via the init method.

So it would look something like this.

const Player = struct{
  .x: usize,
  .y: usize,
  .width: usize,
  .height: usize,
}

pub fn init() Player{
  return Player{
// initializations are here
   }
}

This actually looks pretty similar to Rust. You can optionally do something like const Self = @This(). This allows you to identify your class reference as a Self or anything you choose. Pretty nice for people who come from other languages. I decided not to go with this though.

Next I put a draw function:

    pub fn draw(self: Player) void {
        const origin = rl.Vector2{
            .x = 0,
            .y = 0,
        };

        const rec = rl.Rectangle{
            .x = self.x,
            .y = self.y,
            .height = self.height,
            .width = self.width,
        };

        rl.drawRectanglePro(rec, origin, @as(f32, @floatFromInt(0)), .white);
    }

Here i define the origin as a 2 dimensional vector. And I take my initialization values from the constructor and I update a rectangle. Last I just draw the triangle. But this is all stuff I did yesterday this is just me organizing it better.

The rl identifier is just an alias to the Raylib library.

Last there is an update I need to call. It looked like this:

    pub fn update(self: Player) void {
        self.x += 1;
    }

Ok discovering the problems

One thing I did to try to center the square in the middle of the screen was this:

   return Player{
            .x = rl.getScreenHeight() / 2,
            .y =  rl.getScreenWidth()/ 2,
            .height = 10,
            .width = 10,
        };

Now this math may be incorrect and I'm sure it is. But the point is that r1.getScreenHeight() returns an i32. But all of the draw square functions from Raylib takes in f32. So I had to convert them.

        return Player{
            .x = @as(f32, @floatFromInt(rl.getScreenHeight())) / 2,
            .y = @as(f32, @floatFromInt(rl.getScreenWidth())) / 2,
            .height = 10,
            .width = 10,
        };

Again not perfect due to the precision values now here. But it makes the compiler happy and I plan to fix all of this later.

The one that was most weird was my update. It couldn't update because it was a constant! Then I remember I have to actually pass the address and update the address. A bit of a quirk, but actually it would have worked the same way in Go. However Go would have made a copy of the struct and updated that. Which wouldn't have been ideal for state reasons. Zig makes everything a constant unless you're explict about it. So easy fix.

    pub fn update(self: *Player) void {
        self.x += 1;
    }

So my code looked like this

     if (rl.isKeyDown(.d)) {
            player.update();
            player.draw();
        }
        rl.beginDrawing();

        defer rl.endDrawing();

        rl.clearBackground(.dark_gray);
        player.draw();

And I ended up with a square that could move if hold down the 'D' key.

What did I learn

I learned more zig than game dev today. Again today there was just some hours I set aside to sit back and play with this. Tomorrow I am going to try to draw some more squares (yay) and see if I can get my little square to sit on top of them. So looks like I need to learn some lessons in collision detection.

Following my passion #3: Long overdue update on animation

Brandon Harrell — Thu, 01 Jan 2026 02:56:53 +0000

Long overdue update

So while I know I have no audience here. I just want to apologize for.a long overdue update. I've been building, I just haven't been blogging. This whole documenting my journey thing is kind of new to me. And I to be better at this.

Let's talk about game animation

Ok I am not going to say too much that hasn't been said a lot before. So let's just talk about animation and spritesheets. A lot of games, particularly 2D games rely on spritesheets. This calls back to the old days of flipbook animations.

In this animation you draw multiple frame images (or frames) and you flip through them giving the illusion of motion. 2D games are pretty similar, but instead of having an actual flip book, you have one big image divided into animation.

What you do is you take the frames, calculate the offset of them, and then every single frame you cycle through them. Typical games run 60 frames per second. So if you have a game you must progress the x position that amount of frames.

So what you would have is first, a frame counter. A max length, and a way to progress the sprite sheet that many pixels. The math can be tricky but you get the hang of it after a few days of playing around with it.

I'm not showing any code for this, because well its lost. And I didn't go with spritesheets. I had build an animation system for an asset with sprite-sheets, and then scrapped it after a month or so. I'll explain the pivot and the alternative.

Closing

Bit of a cop out, but I want to keep these brief and digestible. When I try to cram too much in one blog post I can lazy about keeping these update. So I've decided to split this topic up to keep it more manageable.

Following my passion #2: position vector and learning more Zig

Brandon Harrell — Tue, 16 Sep 2025 02:05:55 +0000

Introduction

Ok moving the square

So yesterday I made a bootstrap Raylib project and it was just drawing a square to the screen. Today the goal was to make the square move. Which I did accomplish

How did I do it?

Interesting stuff about Zig

So Zig reminds me a lot of Go, but there are obviously some big differences. I tried to introduce a little code structure to my project by keeping a Player struct.

const Player = struct{
  .x: usize,
  .y: usize,
  .width: usize,
  .height: usize,
}

This is just to define the position and size of our square on the screen. You'll immediately see and issue if you've worked with Raylib, but I'll get into that.

By convention (pretty sure this isn't imposed by the language), you construct your object via the init method.

So it would look something like this.

const Player = struct{
  .x: usize,
  .y: usize,
  .width: usize,
  .height: usize,
}

pub fn init() Player{
  return Player{
// initializations are here
   }
}

Next I put a draw function:

    pub fn draw(self: Player) void {
        const origin = rl.Vector2{
            .x = 0,
            .y = 0,
        };

        const rec = rl.Rectangle{
            .x = self.x,
            .y = self.y,
            .height = self.height,
            .width = self.width,
        };

        rl.drawRectanglePro(rec, origin, \@as(f32, @floatFromInt(0)), .white);
    }

The rl identifier is just an alias to the Raylib library.

Last there is an update I need to call. It looked like this:

    pub fn update(self: Player) void {
        self.x += 1;
    }

Ok discovering the problems

One thing I did to try to center the square in the middle of the screen was this:

   return Player{
            .x = rl.getScreenHeight() / 2,
            .y =  rl.getScreenWidth()/ 2,
            .height = 10,
            .width = 10,
        };

Now this math may be incorrect and I'm sure it is. But the point is that r1.getScreenHeight() returns an i32. But all of the draw square functions from Raylib takes in f32. So I had to convert them.

        return Player{
            .x = @as(f32, @floatFromInt(rl.getScreenHeight())) / 2,
            .y = @as(f32, @floatFromInt(rl.getScreenWidth())) / 2,
            .height = 10,
            .width = 10,
        };

Again not perfect due to the precision values now here. But it makes the compiler happy and I plan to fix all of this later.

    pub fn update(self: *Player) void {
        self.x += 1;
    }

So my code looked like this

     if (rl.isKeyDown(.d)) {
            player.update();
            player.draw();
        }
        rl.beginDrawing();

        defer rl.endDrawing();

        rl.clearBackground(.dark_gray);
        player.draw();

And I ended up with a square that could move if hold down the 'D' key.

What did I learn

Following my passion #1: Raylib, Zig and the Square on screen

Brandon Harrell — Sun, 14 Sep 2025 22:07:50 +0000

Hello, my name is Brandon and I am a Senior Software Engineer/Architect. By day I do event driven programming in Golang. I am mostly a professional programmer, and usually don't finish many personal projects. I hope to change that.

My 30+ year software engineering journey

I started to learn programming at the age of 14. Way back in the 90s. I wanted to learn how to program for one reason only.

TO MAKE GAMES

I ended up not being a game dev. After a really rough start in my career in the early 2000s, I pivoted to Java programming and production support at banks and financial service companies. Then I moved into the telecoim realm. And I have worked on and built many many large skill systems.

I'm not the best in the world but I think I know my domain of programming pretty well. And I've always wanted to do personal projects but I just procrastinate or never stick with it. This year I plan to change that.

September 13, 2025: The journey begins

Ok, ok. So today technically is September 14th, but yesterday I just did planning and design. Today I put some hands on keyboard. So it's my first day actually making my game idea tangible.

Why is September 13th so important? Well its my birthday. I won't go into my personal life, but 2025 has been a year of reflection. And it has not been the smoothest year. Quite the opposite. I've been doing some major soul searching.

I turned 46. I'm seeing the threat of AI on my profession. And if our AI overlord take us over, it will be humans leaning into creativity who will move forward. So that's what I'm doing. I'm being an artist. Reverting to my 14 year-old self, and rediscovering my passion for game programming.

Yeah I love gaming, but I'm not a game developer

I've been interested in Zig for a few years. And I've always had an interest in game dev. So here we are. Learning both in this year. My MVP is to have the first stage done.

So the goal is to learn game development and Zig all within this year. It will be a fun journey I think.

So how is it going so far?

Well I've been using Google Gemini AI as a bit of a sounding board. Its been helping me fill in some of the gaps of my game development. But I gave it explicit instructions not to write any code for me. Just to kind of go over different concepts and ideas with me. Its been going well. I call him "Lil Homie Jimmy".

At first I wanted to use the Mach Enginehttps://machengine.org/. But it uses Zig nightly builds and nominates a build. It's also locked into the ECS pattern, which is probably not a horrible thing for what I'm going to be doing. But I think the Zig build nomination makes my workflow so cumbersome, especially since its only on Zig 0.14. It makes more sense to be on 0.15 and it also doesn't break my toolchain (like ZLS).

So I decided on Raylib. It has a lot of examples in many many languages. So its a great choice for someone who is a novice game dev.

This is what I have so far. It took all day to do this. So not the best start. But this square will serve as a hitbox for my eventual character. This will be a 2D game and an action platformer, so collision detection will make a huge difference here.

What is the game idea?

Its going to be a 2D action platformer. That's all I can say now. And I want to put a big emphasis on boss battles. I think there is a good idea here, but I kind of want to see it to completion before I say too much.

So how are we going to move forward?

Well tomorrow I want to start doing some stuff with the user input. This shouldn't take too long to complete. But it will probably introduce me to some stuff like vector geometry. That's my goal for tomorrow.

Conclusion

If all goes well, this time next year will be my #365th entry. My issues is sticking with stuff, so this is a habit I'm going to hav eto try to break this year.

Learning Zig, day #1

Brandon Harrell — Wed, 05 Jun 2024 12:17:53 +0000

The why

So I have decided to learn Zig. This is kind of an odd decision because I have never had any interest in Zig. But I have had an interest in Rust for years. Just a little about my background. I am a professional Go developer (well was I've been unemployed for 2 weeks). And during my downtime I decided to pick up a new programming language. This will be the 4th professional language I've learned. My first professional language being Java, then Python years later, now Go for the last 8 years.

Toy Program to get started

Anyway I plan writing my own message broker. And for no reason other to see if I can. One of my favorite simple things to write in Go are TCP sockets. So figuring out how to do that in Zig was a priority, surprisingly it's not too bad.

So first they suggest that I create a new Ip4Address. Here it is below.

    const addr = net.Ip4Address.parse("127.0.0.1", 3000);

Alright not too painful. I then have to initialize an Address. This is a struct that takes in an Ip4Address, which I created above. So my next step kind of looks like this.

   var server =  try local_addr.listen(.{.reuse_port=true});
   defer server.deinit();

So what's happening here is pretty cool. We call the "listen" method. Because this can return an error, we call it with "try". This looks suspiciously like an exception. But not to worry, errors are values in Zig, just like Golang. This can alternatively be written like this.

var server =  local_addr.listen(.{.reuse_port=true}) catch |err|{
       //handle value
 };
 defer server.deinit();

So the try semantic is kind of syntactic sugar. Since I'm new to the language and this was my first day using it, I just went with try, but I can see using the "catch" version for better debugging and logging.

Now finally I'm ready to accept a connection, so lets start our loop.

    while(true){
        const conn = try server.accept();
        const message = try conn.stream.reader().readAllAlloc(reader_allocator, 1024);

        print("{s}", .{message});
        reader_allocator.free(message);   
    }

As you can see, we use the "try" syntactic sugar again. Then we obviously read from our connection. What's important is the "readAllAlloc" call. It takes an allocator, and a size which is the size of the allocator. I actually define an "allocator" earlier. I won't get too much into allocators because I only have a super basic understanding of them. But essentially instead of the ownership and borrow checker model found in Rust, we instead can create an allocator structure. We can clean it up whenever we want, but it's usually done via a defer. I'm in a an infinite loop, meaning this will never reach the end of the function. So I an deallocating manually with reader_allocator.free(message).

Here is the fully code:

const std = @import("std");
const net = std.net;
const print = std.debug.print;

pub fn main() !void {

    var gpa = std.heap.GeneralPurposeAllocator(.{}){};

    defer _ = gpa.deinit();

    const reader_allocator = gpa.allocator();

    const addr = try net.Ip4Address.parse("127.0.0.1", 3000);
    const local_addr = net.Address{.in = addr};

    var server =  try local_addr.listen(.{.reuse_port=true});
    defer server.deinit();

    while(true){
        const conn = try server.accept();
        const message = try conn.stream.reader().readAllAlloc(reader_allocator, 1024);

        print("{s}", .{message});
        reader_allocator.free(message);   
    }

}

Thoughts and review so far

So playing around with Zig is actually pretty fun. I've had a lot of false starts with Rust, and it's just hard to get started with. But Zig I was able to just start writing code right away. Zig, while simple, does have a learning curve. But it seems to not be wearing its concepts on its sleeve like Rust. I also think the allocator strategy is genius. And while the Rust borrow checker is also an incredibly good idea, it can make the ownership semantics extremely difficult to work with.

Clearly my program will need some improvements. While this compiles and works, I'm not sending anything back to the client. I also need to build a client as well. Probably put the server in its own package. And I need to figure out what to do with this allocator, because calling it in a loop probably isn't incredibly safe. So I may need to free up memory based on a few conditions, like after a response to the client.

Anyway it's not everyday I'm excited about a new language.