Go on Lorbic

How Go Channels Actually Work

Thu, 13 Aug 2026 18:00:00 +0530

A single unbuffered channel send without an active receiver is enough to silently lock up a production worker pool, leaking memory until your service gets killed by the OS kernel.

On the surface, Go channels look simple: they synchronize concurrent execution without manual mutex management. But under heavy load, a minor oversight in channel sizing or worker coordination blocks the scheduler, leaks memory, or crashes processes with runtime panics.

Part 6: Simulating a Living Facility: Room Derivation, Sunlight Spillover, and Positional SFX

Mon, 10 Aug 2026 10:00:00 +0530

Generating a raw matrix of integer tiles gives you a map layout, but it doesn’t give you a living environment. When I loaded my first level into Derelict Facility, the engine had no concept of what a “Laboratory” or a “Reactor Room” was. It just saw a flat array of walls and floors.

If a player flipped a power terminal inside a room, I had no clean way to know which room lights or doors to toggle without scanning the whole map grid on every frame. If an alarm fired down the hall, it played at full volume regardless of where the player was standing.

Designing a Distributed Job Scheduler in Go: Partitioning, Locking, and Backpressure

Sun, 09 Aug 2026 14:00:00 +0530

Linux crontab is one of the most elegant pieces of software ever written for single-host automation. It is simple, clear, and has kept Unix systems running reliably since 1975.

The problem starts when we take a single-host tool and deploy it across a multi-node cloud setup.

In Relay, a multi-tenant AI API gateway system design, background jobs power core operations: every top of the hour, a job rolls up raw API usage tokens into tenant billing metrics; every 15 minutes, another job scans for expired API keys and purges them from cache; every 30 seconds, a health checker pings upstream LLM provider endpoints.

Part 5: From Terminal Cells to Sprite Maps: Font Fallbacks and Auto-Tiling

Sun, 09 Aug 2026 10:00:00 +0530

Building a terminal-based engine in pure ASCII looks cool for about five minutes. Then you try rendering a complex facility map with corners, T-junctions, and status icons, and raw character cells start feeling incredibly limiting.

Two specific problems hit me immediately when I tried switching to Raylib for graphics. First, drawing wall tiles manually by hand in level files meant placing 16 different corner variations by hand. Second, when I tried rendering a 🚨 warning emoji alongside FiraCode monospace text, Raylib just rendered a missing glyph box (? or □).

Part 4: Refactoring to SoA ECS: Bitmasks and Flat Component Arrays

Sat, 08 Aug 2026 10:00:00 +0530

When I started building Derelict Facility, my initial instinct for game actors was standard Object-Oriented design: create an Entity struct, add pointers for position, sprite, and stats, and store them in a slice ([]*Entity).

It worked fine for five entities. But as soon as I added automated doors, save terminals, and active power grids across a 1000-tile map, keeping track of separate heap pointers became a headache. My Go profiler showed GC pauses spiking while the CPU spent more time chasing heap pointers across non-contiguous memory than actually updating game state.

Constructing Concurrent Inverted Indexes in Go

Tue, 16 Jun 2026 22:00:00 +0530

I spent a Saturday afternoon benchmarking a concurrent inverted index and discovered that a single sync.RWMutex starts to break down at roughly 4 concurrent readers. The degradation is not linear. It is not graceful. It is a cliff.

The inverted index is one of the oldest data structures in information retrieval. It maps terms to the documents that contain them, forming the backbone of every search engine from Elasticsearch to Lucene to Google’s earliest prototypes. The data structure itself is simple. Making it fast under concurrent load is not.

A Love Letter to the L1 Cache

Mon, 15 Jun 2026 19:00:00 +0530

I recently spent four hours staring at a benchmark that didn’t make sense.

It started while working on Derelict Facility, my grid-based game engine in Go. I was trying to tighten the main update loop, specifically the part that iterates over every entity on the map each frame. I pulled out a small benchmark to isolate the cost, and something looked wrong.

I had two Go structs. They held the exact same data: two booleans and a 64-bit integer. I was iterating over a slice of 10 million of these structs, doing a simple addition. They should have been identical in performance.

Why Your Goroutines Need a Speed Limit: Bounded Concurrency in Go

Fri, 10 Apr 2026 10:00:00 +0530

TL;DR: Spawning go func() without a limiter is a recipe for system collapse. This guide details how to use Semaphores and Worker Pools to prioritize predictable stability over absolute speed, protecting downstream dependencies from the thundering herd.

It’s a rite of passage for every Go developer. You receive a list of 10,000 URLs to fetch or 50,000 rows to process. You wrap the workload in an unbounded go func() loop, achieving maximum throughput in milliseconds.

Part 2: Decoupling the Renderer: Terminal to Raylib in One Interface

Mon, 06 Apr 2026 10:00:00 +0530

The biggest architectural mistake you can make when building a game engine is letting the game know how it is being drawn.

When I started building the Derelict Facility engine, the output target was a raw ANSI terminal. The engine calculated A* paths, resolved line-of-sight, and then spewed escape codes (\033[31m) to os.Stdout.

Eventually, I hit the physical limits of terminal emulators: inconsistent character widths (especially for emojis), slow double-buffering, and a hard cap on frame rates. I needed to move to a real, hardware-accelerated graphics library like Raylib.

Part 1: Data-Oriented Design in Go: Why [][]Tile Destroyed My Game Engine

Sun, 05 Apr 2026 10:00:00 +0530

Most game development stories start the same way: install Unity, drag some sprites onto a canvas, and press Play.

I wanted to understand the metal. I set out to build Derelict Facility, a systems-level game engine from scratch in pure Go. No SDL, no OpenGL wrappers, no Ebiten. The goal wasn’t just to ship a game; the goal was to learn the memory layouts and I/O pipelines that modern engines hide behind friendly APIs.

Understanding CPU Caches in Go

Tue, 31 Mar 2026 22:15:00 +0530

When you’re building Go services that handle millions of operations per second, the hardware beneath your abstractions starts to matter. Specifically, the CPU cache hierarchy, and whether your data fits in it.

The Hardware Context: It’s Not Just “RAM”

Your server has 32GB or 64GB of RAM, but the CPU avoids touching it whenever possible. Instead, it works through a chain of caches:

WSL2 Is Slow? Fix /mnt/c/ File System Performance & Go Latency

Sun, 29 Mar 2026 22:30:00 +0530

WSL2 (Windows Subsystem for Linux) has been a godsend for developers who love Linux tools but need/have a Windows environment. But for Go developers, WSL2 isn’t just a “transparent layer”. If configured incorrectly, it becomes the bottleneck that can slow down builds by 3x and introduce mysterious latency in networked services.

This isn’t a failure of WSL2; it’s a failure of understanding the 9p boundary.

Glossary // What is the 9P Boundary?

WSL2 is a Virtual Machine. To let that VM see your Windows files, Microsoft uses the 9P protocol (Plan 9).

What is a Mutex?

Sun, 29 Mar 2026 11:18:00 +0000

Go Struct Field Alignment: How Memory Padding Wastes Your RAM

Sat, 24 Jan 2026 10:00:00 +0530

You write a struct to represent a database entity. Maybe 10 fields, maybe 20. What could possibly go wrong?

Nothing, according to your tests. But somewhere in production, your heap is 30% larger than it should be, your Garbage Collector is working overtime, and your L1 cache is not used properly. The reason? Invisible padding bytes silently inflating every instance of your struct.

This is the story of struct field alignment: a memory optimization that costs nothing to implement but can significantly improve performance.

Memory Mechanics In Go - Stack vs Heap

Mon, 12 Jan 2026 00:10:00 +0530

We often talk about “fast” code in terms of Big O notation or algorithmic complexity. But in systems programming languages like Go, “fast” is often a function of where your data lives in memory.

When optimizing for high throughput, efficient loops and database indexes are only part of the story. Eventually, you have to talk about the Stack and the Heap.

Understanding the difference isn’t just trivia. It is the difference between a service that hums along at 100k OPS with flat latency, and one that chokes on Garbage Collection (GC) pauses every few seconds.

Go Garbage Collector Mechanics: Pacer, GOGC, and Allocation Latency

Wed, 07 Jan 2026 00:21:12 +0530

In the world of high-throughput backend services, we often obsess over the usual suspects of performance: database indexing, network latency, and algorithmic complexity. But recently, while debugging our core gateway service (backend-gw), I encountered a bottleneck that defied standard logic.

The service was CPU-bound, yet active heap usage was surprisingly low (~200MB). P99 latency was spiking at random intervals, but database queries were returning in milliseconds.

The culprit was not the business logic. It was memory management. I was effectively running a Denial-of-Service attack on my own runtime.

Bitmasking In Go

Thu, 17 Apr 2025 02:20:00 +0000

Bitmasking in Go

Bitmasking is one of those computer science tricks that feels like wizardry, until you realize it’s just some clever shifting and binary math. This blog explores the idea, shows how we use it in Go, and why it’s surprisingly useful when working with databases like Couchbase.

What’s Bitmasking?

A bitmask is just an integer where each bit (0 or 1) represents a flag or state. Instead of storing multiple booleans in a slice or map, you cram them into a single int. Fast to compute, fast to store, and great for indexing.

Understanding T and *T method receivers in Go

Sun, 23 Feb 2025 04:33:00 +0000

In Go, method receivers determine whether a method acts on a copy of a value or a reference to it. This choice isn’t just about performance; it affects correctness and behavior, especially when dealing with synchronization primitives (mutex, wait group, etc), slices, and embedded types.

In this post I explore when to use T (a value receiver) vs. *T (a pointer receiver) and why, in most cases, pointer receivers should be the default and preferred.

Go Clean Code Guidelines

Sun, 22 Sep 2024 15:22:00 +0000

Go Clean Code Guidelines for Code Quality and Maintainability.

When it comes to writing clean, maintainable code, there are a few fundamental rules that can help improve the overall structure and quality of your codebase. As engineers, our goal should be to keep things simple, clear, and scalable. With this in mind, here are some guidelines which prioritize code readability, functional clarity, and the overall maintainability of a project. These guidelines are based on principles from clean code, SOLID, and functional programming while emphasizing simplicity over unnecessary complexity.

SOLID and Functional Programming Principles in Go

Sun, 22 Sep 2024 00:03:00 +0000

Let’s go through the SOLID principles and functional programming principles that can apply to your Go codebase. I’ll provide simple Go examples along with brief explanations to show how each principle can improve code quality.

SOLID Principles

Single Responsibility Principle (SRP)

Description: A class or function should have only one reason to change, meaning it should only have one job or responsibility.

Example:

 1// Good: Separate responsibilities into two functions
 2type EmailSender struct{}
 3
 4
 5func (e *EmailSender) SendEmail(to, subject, body string) {
 6 // logic for sending email
 7}
 8
 9
10func formatEmailBody(template string, data map[string]string) string {
11 // logic for formatting the email body
12 return ""
13}
14
15
16// Avoid: Single function doing multiple jobs
17func sendFormattedEmail(to, subject, template string, data map[string]string) {
18 body := formatEmailBody(template, data)
19 // email sending logic mixed with formatting
20}

Open/Closed Principle (OCP)