Any company using Kubernetes eventually starts looking into developing their custom controllers. After all, what’s not to like about being able to provision resources with declarative configuration: Control loops are fun, and Kubebuilder makes it extremely easy to get started with writing Kubernetes controllers. Next thing you know, customers in production are relying on the buggy controller you developed without understanding how to design idiomatic APIs and building reliable controllers.

Low barrier to entry combined with good intentions and the “illusion of working implementation1” is not a recipe for success while developing production-grade controllers. I’ve seen the real-world consequences of controllers developed without adequate understanding of Kubernetes and the controller machinery at multiple large companies. We went back to the drawing board and rewritten nascent controller implementations a few times to observe which mistakes people new to controller development make.

I recently built something interesting and want to share it with you: introducing OpenDAL as a native Go binding.

TLDR; I'll show you a feasible way to build native Go bindings from Rust and C components with the magic power of purego and libffi behinds.

Just like any other dynamically growable container structure, Go slices come with a few gotchas. I don’t always remember all the rules I need to be aware of. So this is an attempt to list some of the most common mistakes I’ve made at least once.

sturdyc eliminates cache stampedes and can minimize data source load in high-throughput systems through features such as request coalescing and asynchronous refreshes. It combines the speed of in-memory caching with granular control over data freshness. At its core, sturdyc provides non-blocking reads and sharded writes for minimal lock contention. The xxhash algorithm is used for efficient key distribution.

A General-purpose Task-parallel Programming Framework for Go, inspired by taskflow-cpp, with Go's native capabilities and simplicity, suitable for complex dependency management in concurrent tasks.

EasyCache is a high-performance, in-memory caching library for Go, supporting multiple eviction policies like FIFO, LRU, LFU, and TTL-based expiration. It is thread-safe, lightweight, and provides built-in metrics.

View the HTTP and HTTPS requests made by any linux program by running httptap -- <command>.

Batching is a well-known optimization technique. You see it everywhere: batch inserts in databases, MGET/MSET in Redis, various bulk APIs. The benefits are clear — it’s faster, cheaper, and less rate-limited. These benefits usually come at the cost of slightly more complex code and some boilerplate.

I recently joined a project where the codebase was written in Go. While the codebase had numerous issues, one stood out: the server restarted unexpectedly and frequently. After examining the server logs, I discovered the culprit—panic-induced crashes in Goroutines. The underlying issue was that the codebase didn’t handle panic recovery in all the Goroutines it started.

Zog is a schema builder for runtime value parsing and validation. Define a schema, transform a value to match, assert the shape of an existing value, or both. Zog schemas are extremely expressive and allow modeling complex, interdependent validations, or value transformations.

genqlient is a Go library to easily generate type-safe code to query a GraphQL API. It takes advantage of the fact that both GraphQL and Go are typed languages to ensure at compile-time that your code is making a valid GraphQL query and using the result correctly, all with a minimum of boilerplate.

Fast, Simple and a cost effective tool to replicate data from Postgres to Data Warehouses, Queues and Storage

Swiss Tables are a form of open-addressed hash table, so let’s do a quick overview of how a basic open-addressed hash table works.

TL;DR

- Some of the wisdom contained in Josh Bloch’s Effective Java book is relevant to Go.
- panic and recover are best reserved for exceptional circumstances.
- Reliance on panic and recover can noticeably slow down execution, incurs heap allocations, and precludes inlining.
- Internal handling of failure cases via panic and recover is tolerable and sometimes beneficial.