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.

I was helping someone get my gokrazy/rsync implementation set up to synchronize RPKI data (used for securing BGP routing infrastructure), when we discovered that with the right invocation, my rsync receiver would just hang indefinitely.

This was a quick problem to solve, but in the process, I realized that I should probably write down a few Go debugging tips I have come to appreciate over the years!

A friend from work messaged me today that they had a hard time because they had used var c chan int instead of c := make(chan int) in their Go code.

I responded by saying that I usually have one rule of thumb i.e. to always use of make() whenever I need a channel or map. That way I can be very sure that I can use those immediately.

They added that the surprising thing was it didn’t panic the program rather they ended up with an infinite loop that ran silently. I got more intrigued about the situation. So many questions started popping up in my mind. Why was I not able to catch it in the code review? Why was there no linter rule that could catch this? What is the point of having a nil channel in Go if I am brainwashing myself to always use make()?

I went on to get some answers and here they are!