antonau.tech

Tricky parts of Golang. The Nil Interface Trap

Wed, 03 Jun 2026 12:00:00 +0200

Few bugs in Go are as disorienting as this one: you return nil from a function, check the result against nil, and the check fails. No type assertion panic, no runtime error — just a quiet wrong answer that sends you down a debugging rabbit hole.

This article breaks down why it happens, what Go is doing under the hood, and how to make sure you never ship this bug.

Tricky parts of Golang. Goroutine Leaks: Patterns, Detection, and Prevention

Thu, 28 May 2026 10:00:00 +0200

A goroutine leak is one of the most insidious bugs in Go. Unlike a memory leak in C, nothing crashes. No panic, no OOM killer. Your service just slowly grows in memory and CPU usage over hours or days until it falls over — or someone notices the goroutine count in a dashboard.

This article covers the three root causes, how to find leaks with the tools built into the standard library, and API design patterns that make leaks structurally impossible.

Tricky parts of Golang. The defer Trap in Loops

Tue, 12 May 2026 10:00:00 +0200

defer is one of Go’s most useful features and one of its most misunderstood. The documentation is precise: a deferred call runs when the surrounding function returns — not when the surrounding block or loop iteration ends. That single sentence is responsible for resource leaks, silent data corruption through named returns, and unnecessary performance overhead that persists until you know to look for it.

Misconception 1: defer Runs at the End of a Block

This is the most common mistake, and it almost always appears inside loops:

Tricky parts of Golang. Escape Analysis and Heap Allocations

Fri, 24 Apr 2026 10:00:00 +0200

Two functions. Nearly identical code. One puts your variable on the stack; the other sends it to the heap, adding GC pressure every time it runs. You cannot tell which is which by reading the code — you need to ask the compiler.

This article explains how Go decides where variables live, how to read the compiler’s decision, and which patterns silently force allocations you did not intend.

Stack vs. Heap: Why It Matters

Memory in a Go program lives in two places:

Tricky parts of Golang. The Slice Header and the Shared Backing Array

Sat, 21 Mar 2026 10:00:00 +0200

Slices are the bread and butter of Go programming. Most developers use them daily without thinking twice — and that comfort is exactly where subtle, load-dependent bugs come from. This article pulls back the curtain on how slices are represented in memory and explains the class of bug that emerges when two slices quietly share the same underlying array.

The Surprise

original := []int{1, 2, 3, 4, 5}
sub := original[1:3] // [2, 3]

sub[0] = 99

fmt.Println(original) // [1 99 3 4 5] — original changed!

We modified sub, but original changed too. No pointer was explicitly shared. This is not a bug in Go — it is the feature working exactly as designed. The surprise comes from not knowing what a slice is at the memory level.

MXFP4 Quantization

Sun, 11 Jan 2026 19:19:35 +0100

1. Quick-look, “in a nutshell”

MXFP4 quantization is a microscaling, 4-bit floating-point compression scheme designed to shrink the memory footprint of deep-learning models without hurting accuracy.

MX = Microscaling — each block of 32 values shares a single scaling factor, giving the block adaptive dynamic range
FP4 = floating-point values stored in 4 bits each (E2M1 format: 1 sign + 2 exponent + 1 mantissa)

The format was standardised in 2023 by the Open Compute Project (OCP), backed jointly by AMD, Arm, Intel, Meta, Microsoft, NVIDIA, and Qualcomm.

Tricky parts of Golang. Preemption in Go

Mon, 18 Aug 2025 19:01:19 +0000

In the Go runtime, the scheduler is the engine that manages how thousands of goroutines are multiplexed onto a limited number of operating system threads. To ensure system responsiveness and prevent “resource hogging,” Go employs a mechanism called preemption.

This article explores the internal mechanics of the Go scheduler, the transition from cooperative to non-cooperative preemption, and real-world case studies from high-scale systems.

Why do we need it?

Imagine you’re running a tight loop that never calls anything else. In a cooperative system, that goroutine would hog the CPU forever. With preemption, the runtime periodically interrupts it, giving other goroutines a chance to run. That’s how Go keeps the “green threads” from starving each other.

Search

Mon, 24 Mar 2025 23:00:00 -0300

Search

Here you can search for indexable pages, like posts and alike. There’s also support for URL param “q” which then auto searches upon page load event.

It's necessary to enable Javascript