Each chapter focuses on one HTTP concept and shows the same runnable example across net/http, Chi, Gin, Echo, Fiber, and Mizu. The key idea is that the README files are the single source of truth. All example code is generated from them and verified to compile and run (some may contain errors, let me build proper CI/CD later).

It is meant as a practical reference and a way to understand where frameworks differ in responsibility and wiring, not just syntax.

Book view here: https://github.com/go-mizu/go-fw/blob/main/BOOK.md

I've kept running into the same problems in popular Go frameworks: hidden context mutation, magic middleware ordering, reflection-heavy binding, and APIs that slowly drift away from the standard library. The Gin ecosystem in particular has accumulated a lot of technical debt and footguns, which this post summarizes well: https://eblog.fly.dev/ginbad.html

Mizu is deliberately boring by design:

  - Built directly on Go 1.22 http.ServeMux
  - Explicit middleware chains with clear scoping
  - No reflection, no codegen, no global state
  - A real request context type that still interoperates with net/http
  - First class graceful shutdown and error handling

Docs: https://docs.go-mizu.dev/overview/intro

https://savannah.gnu.org/users/ttn

> For the love of clean code history, let's remember we're not monkeys banging on keyboards; we're educated, civilized human beings.

A single `events` table falls apart as the system grows, and untyped JSONB data in `event_data` column just moves the mess into code. Event payloads drift, handlers fill with branching logic, and replaying or migrating old events becomes slow and risky. The pattern promises clarity but eventually turns into a pile of conditionals trying to decode years of inconsistent data.

A simpler and more resilient approach is using the database features already built for this. Stored procedures can record both business data and audit records in a controlled way. CDC provides a clean stream for the tables that actually need downstream consumers. And even carefully designed triggers give you consistent invariants and auditability without maintaining a separate projection system that can lag or break.

Event sourcing works when the domain truly centers on events, but for most systems these database driven tools stay cleaner, cheaper, and far more predictable over time.

You rarely replay them to reconstruct business state; you just pump them into analytics or enrichment pipelines.

With only half serious intent, I think only the real wizard types, like Jarred Sumner (Bun) and Mitchell Hashimoto (Ghostty), who understand both low level systems and higher level languages, should be writing big tools in Zig. The tough part in the next few years will not be building things, it will be keeping them alive if the authors step away or the ecosystems move in a different direction.

Enough rant, now back on some reasons for why choosing Zig:

   - Cross platform tools with tiny binaries (Zig's built in cross compilation avoids the complex setup needed with C)
   - System utilities or daemons (explicit error handling instead of silent patterns common in C)
   - Embedded or bare metal work (predictable rules and fewer footguns than raw C)
   - Interfacing with existing C libraries (direct header import without manual binding code)
   - Build and deployment tooling (single build system that replaces Make and extra scripts)

Hm, i can see a good use case when we want to have reproducible builds from go packages, including its C extensions. Is that your use case, or are you aiming for multi-environment support of your compiled "CGO extensions"

need to bundle a lot of C libraries, some using dynamic linking and some using static linking, and I need to deploy them on different operating systems, including some that are difficult to work with like RHEL. Right now the builds are slow because I use a separate Dockerfile for each platform and then copy the binary back to the host. With Zig CC I could build binaries for different platforms and architectures without using Docker.