For many years, I've used third-party packages to help organize and manage middleware in my Go web applications. In small projects, I often used alice to create middleware 'chains' that I could reuse across multiple routes. And for larger applications, with lots of middleware and routes, I typically used a router like chi or flow to create nested route 'groups' with per-group middleware.

But since Go 1.22 introduced the new pattern matching functionality for http.ServeMux, where possible I've tried to drop third-party dependencies from my routing logic and shift to using just the standard library.

But going all-in on the standard library leaves a good question: how should we organize and manage middleware without using any third-party packages?

The original motivation for the creation of Bloom filters is efficient set membership, using a probabilistic approach to significantly reduce the time and space required to reject items that are not members in a certain set.

The data structure was proposed by Burton Bloom in a 1970 paper titled "Space/Time Trade-offs in Hash Coding with Allowable Errors". It's a good paper that's worth reading.

Go is a powerful language known for its simplicity, speed, and concurrency model. But the Go community also traditionally takes a strong stance against frameworks and centralized conventions — and that’s where many teams, especially those coming from structured environments like Rails, Django, or FastAPI, hit a wall.

This post explores the structural gap in Go development, why it exists, and how Encore is helping fill that void with a convention-driven framework that brings clarity, consistency, and productivity back to backend development.

Odin is a general-purpose systems programming language authored by Bill “gingerBill” Hall. Designed as a modern alternative to C, Odin emphasizes simplicity, performance, and readability without sacrificing control over low-level details.

The website says it’s “data-oriented”, and features such as SOA (structs-of-arrays) and implicit zero initialization tie into that. Despite this focus, the language surprisingly has dynamic maps and arrays built into the language itself. While the memory is still manually managed, it’s uncommon to see such built-ins.

This perhaps sets the tone of Odin: it tries to be ergonomic and easy to write by offering a lot out of the box. Odin also comes with “vendor”, containing bindings to a wide variety of popular libraries. This makes the language very easy to get into.

This is a native WebP encoder written entirely in Go, with no dependencies on libwebp or other external libraries. Designed for performance and efficiency, this encoder generates smaller files than the standard Go PNG encoder and is approximately 50% faster in execution.

Currently, the encoder supports only WebP lossless images (VP8L).

A Go implementation of the Model Context Protocol (MCP), enabling seamless integration between LLM applications and external data sources and tools.

Nerdlog is a fast, remote-first, multi-host TUI log viewer with timeline histogram and no central server. Loosely inspired by Graylog/Kibana, but without the bloat. Pretty much no setup needed, either.

A lightweight, zero-configuration HTTP request visualizer and debugger for Go web applications during local development.

F2 is a cross-platform command-line tool for batch renaming files and directories quickly and safely. Written in Go!

Git-native dotfiles management that doesn't suck.

Move your dotfiles to ~/.config/lnk, symlink them back, and use Git like normal. Supports both common configurations and host-specific setups.

Gokapi is a simple, self-hosted file sharing server with automatic expiration and encryption support — ideal for teams or individuals who want privacy, control, and no clutter.

Tinyauth is a simple authentication middleware that adds a simple login screen or OAuth with Google, Github and any provider to all of your docker apps. It supports all the popular proxies like Traefik, Nginx and Caddy.

TL;DR

- Go has now standardised iterators.
- Iterators are powerful.
- Being functions under the hood, iterators can be closures.
- The classification of iterators suggested by the documentation is ambiguous.
- Dividing iterators into two categories, “pure” and “impure”, seems to me preferrable.
- Whether iterators should be designed as “pure” whenever possible is unclear.

After spending five years as a JavaScript developer building both frontend and backend systems, I spent the last year transitioning to Go for server-side code. During that time I couldn't help but notice the differences between syntax, fundamentals, practices, and runtime environments between the languages and the effects they had on actual runtime performance and developer productivity.

For years in Go, I’ve used many different logging libraries, from logrus to zap. After the release of slog into Go standard library, I immediately embraced it. It’s clever design made it so versatile and easy to use, and has already accumulated an enormous amount of libraries in the ecosystem.

Go offers an exceptional language and an impressive ecosystem of tools. However, it presents a notable challenge when integrating with C code via cgo. While building and distributing pure Go binaries across various platforms is straightforward — often requiring just a few parameter adjustments — the process becomes considerably more complex when C dependencies are introduced.

Go binary size SVG treemap