DEV Community: Athreya aka Maneshwar

Making Claude Sound Like Optimus Prime

Athreya aka Maneshwar — Mon, 25 May 2026 19:16:26 +0000

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback for improving the project.

My terminal just told me to roll out.

I'm not joking.

I made Claude Code sound like Optimus Prime, and now every coding session feels like I'm leading the Autobots into battle against a poorly-indented JSON file.

How It Actually Works

There's a Claude Code plugin called sound-fx by 6m1w that hooks into Claude's lifecycle events and plays themed sound effects. So:

You type claude → Optimus boots up "Autobots roll out!"
You send a prompt → "Understood, it will be done."
You exit → "We are here. We are waiting!"

It uses Claude Code's built-in hooks (SessionStart, UserPromptSubmit, Stop, Notification, etc.) so it's not jank, it's genuinely integrated.

The Setup

/plugin marketplace add 6m1w/claude-sound-fx
/plugin install sound-fx@claude-sound-fx

Then run the setup wizard to pick your theme:

/sound-fx:setup

I made a quick video walkthrough showing the whole thing:

Other Themes If Optimus Isn't Your Vibe

The plugin ships with 12 themes. A few highlights:

JARVIS — calm, British, makes you feel like Tony Stark
GLaDOS — passive-aggressive AI that mocks your errors
Pikachu — chaotic gremlin energy
WoW Peon — "Ready to work!" reluctant overworked vibes
Mechanical Keyboard — pure ASMR clack clack clack

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

How Bf-Tree Keeps Mini-Pages Small, Hot, and Cheap to Evict

Athreya aka Maneshwar — Sun, 24 May 2026 18:09:02 +0000

Mini-pages are central to Bf-Tree performance, but they cannot grow forever.

If every insert, update, and tombstone remained in memory indefinitely, insertion cost would increase and memory would fill with stale records.

Bf-Tree continuously reorganizes mini-pages through merges, copying, and eviction.

When Does a Mini-Page Merge?

The paper describes two situations where a mini-page is merged back into its leaf page:

The mini-page becomes too large
The mini-page becomes cold (rarely accessed)

Since records inside a mini-page remain sorted, insertion cost rises as it grows.

Mini-page size increases

512B → 1KB → 2KB → ...

Insertion overhead rises

When a mini-page exceeds roughly 2KB, Bf-Tree merges it with the leaf page and produces a larger 4KB mini-page mirroring the leaf.

The merge process is roughly:

Locate leaf page
      ↓
Check available space
      ↓
Split leaf if needed
      ↓
Merge mini-page records
      ↓
Discard old mini-page

The old memory can then be reused.

This keeps write buffering useful without letting mini-pages become expensive secondary indexes.

Copy-On-Access Prevents Hot Data From Being Evicted

Bf-Tree stores mini-pages in a circular buffer.

Suppose a mini-page is close to eviction but suddenly becomes active again.

Instead of keeping it in place:

Old mini-page
      ↓
Copy to buffer tail
      ↓
Mark old copy as tombstone

The frequently accessed mini-page effectively receives a second life.

Hot data moves away from eviction boundaries.

Cold data moves toward disk.

This resembles a lightweight cache promotion strategy.

Evicting Records Instead of Evicting Entire Pages

One interesting detail in the paper is that Bf-Tree can evict individual cold records.

Each record maintains a reference bit:

Accessed recently → keep
Not accessed → evict

During copy-on-access:

Hot records remain in memory
Cold cache records are discarded immediately
Dirty records (insertions/tombstones) trigger merge with leaf pages

So a mini-page gradually evolves:

Before:
[A][B][C][D][E]

Only A and D are hot

After:
[A][D]

Memory becomes concentrated around active keys.

This is much finer-grained than traditional page caches, where an entire page often survives because one record is frequently accessed.

Leaf Splits Still Exist

Despite the redesign, Bf-Tree has not eliminated classic B-Tree behavior.

Leaf pages still split when full.

The difference is where inserts land first:

Traditional B-Tree:

Insert → Leaf page → Possible split

Bf-Tree:

Insert → Mini-page
            ↓
       Merge/Evict
            ↓
       Possible leaf split

A split happens later, after buffering absorbs multiple writes.

Remaining mini-page records are compared against the split key and distributed across new leaf pages.

This delays structural modification and reduces immediate disk work.

The Bigger Pattern

Across merges, copy-on-access, record eviction, and splits, Bf-Tree repeatedly applies the same idea:

Mini-pages are not just a cache—they behave more like a continuously self-cleaning write buffer.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

Range Scans and Tombstones in Bf-Tree

Athreya aka Maneshwar — Sat, 23 May 2026 19:33:31 +0000

Traditional point lookups are where Bf-Tree shines: a mini-page may satisfy reads without touching the underlying leaf page.

But range scans behave differently.

Why Range Scans Still Need Leaf Pages

Suppose we need all keys between 1000 and 2000.

A mini-page only contains recent modifications (insertions, updates, tombstones), not the complete ordered dataset.

To produce an accurate range result, Bf-Tree must:

Scan records inside the mini-page
Load and scan the corresponding leaf page
Merge both views
Return a consistent ordered result

This means mini-pages alone cannot eliminate I/O during range scans.

The merge ensures recent writes override stale leaf-page contents.

Growing Mini-Pages Into Full Cached Pages

The paper proposes an optimization for frequently scanned ranges.

Instead of repeatedly loading the leaf page, a hot mini-page can expand until it becomes a full-page cache inside the circular buffer.

At that point Bf-Tree behaves less like record caching and more like traditional page caching.

The benefit is subtle but important:

Efficient repeated range scans
Faster negative lookups ("record does not exist")
Better handling of gaps between keys
Support for mechanisms such as gap locking

Caching a page means caching both existing records and absence between records.

That absence matters.

Delete Is Just Inserting a Tombstone

Deletion in Bf-Tree does not immediately remove data from the leaf page.

Instead:

DELETE key=42

↓

Insert tombstone into mini-page

Future reads encounter the tombstone and return not found without loading the leaf page.

Later, when the mini-page merges back:

Leaf page + Tombstone
↓

Physical deletion

Deletes become deferred work.

Updates Behave Like Inserts

Updates follow the same idea.

Changing a value:

UPDATE key=42 -> new_value

↓

Write new record into mini-page

Subsequent reads see the updated version directly from memory.

Only during merge does the leaf page become permanently updated.

So in Bf-Tree:

Insert → append to mini-page
Update → append newer version to mini-page
Delete → append tombstone to mini-page

Almost everything becomes "write now, reconcile later."

That design is one reason Bf-Tree reduces random writes while keeping reads fast.

Rate Limiting Strategies in Go: Token Bucket, Leaky Bucket, and Sliding Window

Athreya aka Maneshwar — Wed, 20 May 2026 19:07:53 +0000

Every backend service eventually meets a client that does not know when to stop. Sometimes it is a buggy retry loop, sometimes it is a scraper, sometimes it is your own well-meaning cron job firing a thousand requests in the same second.

The fix is the same: rate limiting.

In this post we will walk through the three algorithms you will encounter again and again — token bucket, leaky bucket, and sliding window — and how to actually use them in Go without writing them from scratch.

Go has solid, well-tested libraries for each, and unless you have a very good reason, you should use them.

We will keep this single-node.

Distributed rate limiting with Redis is its own rabbit hole, and I will save that for a follow-up post.

The three algorithms in one minute

Before touching code, here is the mental model you actually need.

Token bucket has a bucket that holds tokens.
Tokens are added at a steady rate up to some capacity.
Every request takes a token. No token, no request.
Because the bucket can fill up, it allows short bursts — useful when you want to be strict on average but tolerant of brief spikes.

Leaky bucket flips the perspective.
Requests go into a bucket; the bucket drains (leaks) at a steady rate.
If the bucket is full, new requests are dropped or made to wait.
It enforces a strict, smooth output rate. No bursts.

Sliding window counts requests inside a moving time window.
If you say "100 requests per minute," it really means "no more than 100 in any 60-second span."
It is the most accurate of the three but also the most expensive to compute precisely.

A quick comparison:

Algorithm	Allows bursts?	Output shape	Typical use
Token bucket	Yes	Bursty within limits	API endpoints, user quotas
Leaky bucket	No	Perfectly smooth	Outbound calls to a strict upstream
Sliding window	Configurable	Accurate over time	"N per minute" billing-style limits

Now let us actually use them.

1. Token bucket with `golang.org/x/time/rate`

The golang.org/x/time/rate package is the de facto standard for token bucket rate limiting in Go.

It is an official Go subrepository — same maintainers as the standard library, just versioned separately so it can evolve outside the standard library's compatibility lockstep.

You still have to go get it.

go get golang.org/x/time/rate

The core type is rate.Limiter.

You create one with NewLimiter(r, b) where r is the refill rate (tokens per second) and b is the burst size (bucket capacity).

package main

import (
    "context"
    "fmt"
    "time"

    "golang.org/x/time/rate"
)

func main() {
    // 5 tokens per second, bucket holds up to 10
    limiter := rate.NewLimiter(5, 10)

    ctx := context.Background()
    for i := 0; i < 20; i++ {
        // Wait blocks until a token is available (or ctx is cancelled)
        if err := limiter.Wait(ctx); err != nil {
            fmt.Println("error:", err)
            return
        }
        fmt.Printf("request %d at %s\n", i, time.Now().Format("15:04:05.000"))
    }
}

Limiter gives you three methods, and the difference between them is the whole point of the package:

Allow() — returns true if a token is available right now, otherwise false. Non-blocking. Use this when you want to drop excess requests (e.g. return 429 Too Many Requests).
Wait(ctx) — blocks until a token is available. Respects context cancellation. Use this for background workers that should slow down, not fail.
Reserve() — returns a Reservation telling you how long to wait. Use this when you want to make the decision yourself — for example, fail fast if the delay exceeds some threshold.

Drop-style: HTTP middleware with `Allow()`

The most common use case is "limit incoming HTTP requests and reject the overflow." Here is the middleware:

package main

import (
    "encoding/json"
    "net/http"

    "golang.org/x/time/rate"
)

func rateLimitMiddleware(next http.Handler) http.Handler {
    // 10 req/sec sustained, 20 burst
    limiter := rate.NewLimiter(10, 20)

    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if !limiter.Allow() {
            w.Header().Set("Content-Type", "application/json")
            w.WriteHeader(http.StatusTooManyRequests)
            json.NewEncoder(w).Encode(map[string]string{
                "error": "rate limit exceeded, please retry later",
            })
            return
        }
        next.ServeHTTP(w, r)
    })
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("hello\n"))
    })

    http.ListenAndServe(":8080", rateLimitMiddleware(mux))
}

That is it. One limiter, shared across every request, dropping anything over 10/sec with a 20-request burst headroom.

Per-client limiting

A single global limiter is rarely what you want.

Usually you want each client (IP, API key, user ID) to have its own bucket so one noisy client cannot starve everyone else.

The pattern is a map of limiters keyed by client identifier.

package main

import (
    "net"
    "net/http"
    "sync"
    "time"

    "golang.org/x/time/rate"
)

type clientLimiter struct {
    limiter  *rate.Limiter
    lastSeen time.Time
}

type IPRateLimiter struct {
    clients map[string]*clientLimiter
    mu      sync.Mutex
    rate    rate.Limit
    burst   int
}

func NewIPRateLimiter(r rate.Limit, b int) *IPRateLimiter {
    rl := &IPRateLimiter{
        clients: make(map[string]*clientLimiter),
        rate:    r,
        burst:   b,
    }
    // Janitor: evict idle clients every minute
    go rl.cleanup()
    return rl
}

func (rl *IPRateLimiter) getLimiter(ip string) *rate.Limiter {
    rl.mu.Lock()
    defer rl.mu.Unlock()

    c, ok := rl.clients[ip]
    if !ok {
        lim := rate.NewLimiter(rl.rate, rl.burst)
        rl.clients[ip] = &clientLimiter{limiter: lim, lastSeen: time.Now()}
        return lim
    }
    c.lastSeen = time.Now()
    return c.limiter
}

func (rl *IPRateLimiter) cleanup() {
    for {
        time.Sleep(time.Minute)
        rl.mu.Lock()
        for ip, c := range rl.clients {
            if time.Since(c.lastSeen) > 3*time.Minute {
                delete(rl.clients, ip)
            }
        }
        rl.mu.Unlock()
    }
}

func (rl *IPRateLimiter) Middleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // RemoteAddr is host:port; we want the host as the key
        host, _, err := net.SplitHostPort(r.RemoteAddr)
        if err != nil {
            host = r.RemoteAddr
        }
        if !rl.getLimiter(host).Allow() {
            http.Error(w, "rate limit exceeded", http.StatusTooManyRequests)
            return
        }
        next.ServeHTTP(w, r)
    })
}

A few things to note. First, the janitor goroutine: without it the map grows forever as new IPs keep showing up.

Second, r.RemoteAddr is host:port, so if you use it as the map key directly, the same client on a different ephemeral port gets a fresh bucket — which is not what you want. net.SplitHostPort fixes that.

Third, in any real deployment behind a load balancer or CDN, even the host portion of RemoteAddr is your proxy's IP — you need to extract the client IP from X-Forwarded-For or X-Real-IP (and verify the proxy is trusted, or you have just made spoofing trivial).

Wait-style: throttling outbound calls

When you are the client hitting some upstream API with a 100 req/sec ceiling, you want to slow down, not error out.

Wait is the right tool here.

func fetchAll(ctx context.Context, urls []string) {
    // ~100/sec, burst of 1 (no headroom beyond the steady rate)
    limiter := rate.NewLimiter(rate.Every(10*time.Millisecond), 1)

    var wg sync.WaitGroup
    for _, u := range urls {
        if err := limiter.Wait(ctx); err != nil {
            break // context cancelled
        }
        wg.Add(1)
        go func(u string) {
            defer wg.Done()
            fetch(u)
        }(u)
    }
    wg.Wait()
}

Two things worth flagging in this snippet.

First, burst of 1 means a single token sits in the bucket, so the first call returns immediately and the rest are spaced ~10ms apart.

A burst of 0 would reject everything and Wait would block forever — 1 is the minimum useful value when you want "no real burst headroom."

Second, the Wait has to happen before the goroutine spawns, not inside it. If you put it inside, you launch a thousand goroutines in a microsecond and they all race through Wait together — you have throttled goroutine starts, but the actual HTTP calls all fire as soon as their tokens come in, which is not the same as throttling the calls.

Doing the wait in the calling loop and then spawning is what gives you actual rate-limited outbound traffic.

rate.Every(d) is a small helper that converts a desired interval into a rate.Limit. rate.Every(10*time.Millisecond) is the same as rate.Limit(100) but reads more naturally when you are thinking in terms of "one request every N milliseconds."

2. Leaky bucket with `go.uber.org/ratelimit`

Token bucket allows bursts.

Sometimes you do not want that.

If you are calling an upstream that absolutely cannot tolerate spikes — say, a partner API that throttles you on the millisecond, not the second — you want a leaky bucket: smooth, evenly-spaced output.

Uber's go.uber.org/ratelimit is the simplest leaky-bucket implementation in the Go ecosystem. The whole API is one method: Take().

go get go.uber.org/ratelimit

package main

import (
    "fmt"
    "time"

    "go.uber.org/ratelimit"
)

func main() {
    rl := ratelimit.New(100) // 100 ops/sec, evenly spaced

    prev := time.Now()
    for i := 0; i < 10; i++ {
        now := rl.Take()
        fmt.Println(i, now.Sub(prev))
        prev = now
    }
}

If you run this, every iteration after the first will print roughly 10ms.

The limiter does not give you 100 in a burst and then make you wait — it spaces them out exactly.

That is the leaky bucket guarantee.

Slack: a controlled amount of burstiness

Pure leaky bucket can be too strict.

If your producer is slightly bursty by nature, you may not want every single hiccup to cause queueing.

Uber's library has a "slack" knob for this.

With slack, the limiter can accumulate a small number of unspent requests during idle periods and let you burn through them in a burst later.

Worth being precise about what slack is, because it is not the same thing as a token bucket's burst capacity.

A token bucket refills continuously up to its capacity, so even a steady stream of requests can build up headroom if it briefly outpaces the consumer.

Slack only accumulates during idle time — if you are calling Take() continuously, slack does nothing.

It is a one-shot "you went quiet, so we will let you catch up" allowance, not an ongoing buffer.

// Default: allows up to 10 slack tokens (small built-in burst tolerance after idle)
rl := ratelimit.New(100)

// Strict mode: zero slack, perfectly even spacing
rl := ratelimit.New(100, ratelimit.WithoutSlack)

// Custom slack
rl := ratelimit.New(100, ratelimit.WithSlack(50))

Note that WithoutSlack is a variable, not a function — no parentheses.

Per-minute and other windows

By default, New(n) means "n per second." If you want per-minute or per-hour, use Per:

rl := ratelimit.New(5, ratelimit.Per(time.Minute)) // 5 per minute

When to pick Uber's library over `x/time/rate`

The honest answer is: only when you specifically need leaky-bucket semantics. x/time/rate can do almost everything Uber's library does and more (context support, Allow/Reserve semantics, dynamic rate changes).

But if your requirement is "evenly spaced output, no bursts," ratelimit.New(n) is one line and you are done.

One caveat: the library is stable and widely used, but not actively iterated on.

That is usually fine for something this small and well-defined — but if you want a library with more momentum behind it, x/time/rate is the safer pick.

3. Sliding window: when "N per minute" really means N

Token bucket and leaky bucket reason about rate.

They give you very good average-rate enforcement, but they do not give you an exact "no more than N requests in any rolling 60-second window" guarantee.

Sometimes that exact-count semantics is what you actually need — billing limits, login attempt windows, fairness across tenants.

The clean way to do this single-node is to keep a sorted slice of request timestamps per key, and on each request: evict timestamps older than the window, then check if the count is under the limit. Here is a self-contained implementation:

package ratelimit

import (
    "sort"
    "sync"
    "time"
)

type SlidingWindow struct {
    limit    int
    window   time.Duration
    requests map[string][]time.Time
    mu       sync.Mutex
}

func NewSlidingWindow(limit int, window time.Duration) *SlidingWindow {
    return &SlidingWindow{
        limit:    limit,
        window:   window,
        requests: make(map[string][]time.Time),
    }
}

func (sw *SlidingWindow) Allow(key string) bool {
    sw.mu.Lock()
    defer sw.mu.Unlock()

    now := time.Now()
    cutoff := now.Add(-sw.window)

    // Timestamps are appended in order, so we can binary-search the cutoff.
    timestamps := sw.requests[key]
    i := sort.Search(len(timestamps), func(i int) bool {
        return timestamps[i].After(cutoff)
    })
    timestamps = timestamps[i:]

    if len(timestamps) >= sw.limit {
        sw.requests[key] = timestamps
        return false
    }

    sw.requests[key] = append(timestamps, now)
    return true
}

Usage:

sw := NewSlidingWindow(100, time.Minute) // 100 requests per rolling minute

if !sw.Allow("user:42") {
    // reject
}

This is the "sliding log" variant — exact, but memory is O(limit × active_keys).

For high limits (say, 10k req/min across many keys), that becomes real memory.

The standard fix is the sliding window counter variant: keep two adjacent fixed windows (the current and previous minute), each with a single integer count, and estimate the rolling count as count_current + count_previous × (1 - elapsed_fraction_of_current_window).

You lose a bit of precision near window boundaries but drop from O(limit) per key to O(1).

For most real workloads, the simple log version above is fine; reach for the counter version when memory becomes a problem.

You also want a janitor here, same as the IP limiter, to evict keys nobody has hit in a while.

A word on distributed rate limiting

Everything above runs in a single process.

The moment you scale to two instances of your service behind a load balancer, your limits are effectively doubled — each instance has its own bucket.

For a single-instance side project this does not matter.

For anything serious, you need a shared store.

The standard answer is Redis.

The github.com/go-redis/redis_rate package implements GCRA (a leaky-bucket variant) on top of Redis with a single Lua script per check, which keeps it atomic and fast. Roughly:

limiter := redis_rate.NewLimiter(rdb)
res, _ := limiter.Allow(ctx, "user:42", redis_rate.PerSecond(10))
if res.Allowed == 0 {
    // reject
}

I will cover the Redis side of this — including the Lua scripts, why GCRA wins over naive sliding windows at scale, and how to handle Redis going down — in a follow-up post.

For now, just know that when you outgrow single-node limiting, this is the next stop.

Which one should you use?

If you remember one thing from this post, remember this:

Default to golang.org/x/time/rate. It is well-tested, context-aware, and covers 90% of cases. Use Allow for HTTP servers, Wait for outbound clients.
Reach for go.uber.org/ratelimit when you specifically need evenly spaced output and no bursts.
Roll a sliding window when your requirement is genuinely "no more than N in any rolling window of duration W" and average-rate enforcement is not enough.

The biggest mistake I see is people writing their own token bucket from scratch and getting the math subtly wrong — off-by-one on the burst size, races on the refill, drift over long runs. The libraries exist. Use them.

Now go put a 429 in front of whatever is currently melting your server.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

What Happens When You Run `npm run dev`

Athreya aka Maneshwar — Tue, 19 May 2026 18:45:40 +0000

You've run npm run dev approximately 1,000 times in your life.

You've watched the terminal blink.

You've switched to the browser.

Magic happened.

But do you actually know what's going on? Like, really know?

Today we go all the way down the hole understanding shell, process spawning, module graphs, Hot Module Replacement, React Fast Refresh.

Step 0: You press Enter

npm run dev

Your shell looks up npm in your PATH and finds it — often inside whatever directory nvm installed Node into, or at a system path like /usr/local/bin/npm. It hands control to the npm CLI, which is itself just a Node.js script.

npm then does one thing: reads your package.json.

{
  "scripts": {
    "dev": "vite"
  }
}

It finds "dev": "vite" and prepares to run it.

Step 1: npm spawns a child process

npm temporarily adds ./node_modules/.bin to your PATH, then spawns a child process running the dev command.

So "vite" resolves to ./node_modules/.bin/vite, which is a symlink to the actual Vite binary inside node_modules/vite/bin/vite.js.

No magic. It's just Node running a JS file.

Step 2: Vite boots up

Vite reads your vite.config.js (or .ts), registers plugins, and does something really clever before anything is served.

The esbuild pre-bundling trick

Vite uses esbuild written in Go, absurdly fast to pre-process your node_modules dependencies.

It does two things:

Converts CommonJS to ESM. Browsers can't natively load require(). esbuild rewrites it.
Collapses packages with many internal files into one. lodash has 600+ tiny files. esbuild merges them so the browser makes one request, not 600.

The result is cached in .vite/deps/. Touch node_modules? Cache busts.
Otherwise it skips this step entirely on restart.

Step 3: The dev server is just... an HTTP server

Vite starts a plain Node.js HTTP server on localhost:5173.

No webpack dev server magic, no complex middleware chains.

When the browser requests a file, Vite:

Reads it from disk
Transforms it on-the-fly (JSX → JS, TypeScript → JS, .css → injected <style>)
Serves it as a native ES Module

The browser itself handles module resolution using <script type="module">.

The key insight: Vite doesn't bundle your source code in dev mode at all.

The browser fetches each file individually as an ES module.

This is why Vite's dev startup is near-instant regardless of your project size it only processes what the browser actually asks for.

Each arrow is a real HTTP request. The browser is doing the graph traversal for you.

Step 4: The module graph

As files are requested, Vite builds an internal module dependency graph a map of who imports what.

This graph is lazy, only nodes that get requested exist in it.

If you never navigate to a route, those components are never fetched, never in the graph.

This is the structure that makes HMR fast.

When a file changes, Vite doesn't scan all your code.

It just walks this graph.

Step 5: You save a file — here's where it gets interesting

5a. OS notifies Vite immediately

Vite uses chokidar which wraps OS-native file system events:

OS	API	Mechanism
Linux	`inotify`	Kernel watches inodes directly
macOS	`FSEvents`	Core Services file-system event API
Windows	`ReadDirectoryChangesW`	Win32 API

Zero polling. The OS taps Vite on the shoulder the moment your editor flushes to disk.

5b. Walk the graph, find the HMR boundary

Vite walks up the module graph from the changed file, looking for the first ancestor that has registered an HMR handler via import.meta.hot.accept().

With React, you never write import.meta.hot.accept() yourself.

The @vitejs/plugin-react plugin (which uses React Fast Refresh) automatically injects this into every component file at transform time. It's invisible to you.

If no boundary is found all the way up to main.jsx full page reload.

You'll see this happen when you edit vite.config.js or a non-component JS utility that isn't HMR-aware.

5c. Server re-transforms only the changed file

Vite re-runs just Button.jsx through its plugin pipeline JSX transform, any Babel plugins, etc.

The result is a fresh ES module in memory.

5d. Browser fetches the new module via dynamic import

The HMR client (a small script Vite injects into your page) is told an update is available and calls:

import('/components/Button.jsx?t=1718023456789')

The ?t=timestamp query param is the cache-buster. The browser sees a URL it hasn't fetched before, makes a real HTTP request, gets the new module.

5e. The module swap — `hot.dispose` and `hot.accept`

Vite's HMR runtime is built around two functions you (or, with React, the plugin) register on import.meta.hot:

// In a module that wants to handle its own updates:

// Clean up before this module is replaced —
// cancel timers, unsubscribe, remove listeners.
import.meta.hot.dispose((data) => {
  clearInterval(timer)
})

// Receive the freshly imported module and re-wire things.
import.meta.hot.accept((newModule) => {
  // newModule is the updated exports
})

A subtle but important detail: Vite's HMR doesn't literally swap the original imported module object for everyone up the chain.

The accepting module i.e the HMR boundary is responsible for taking the new exports and applying them.

That simplified model is what lets Vite skip the expensive work of rewriting every importer, and it's enough for almost every real dev scenario.

dispose is where you cancel a setInterval, unsubscribe from a store, or remove an event listener, anything that would leak if the old module just got abandoned.

Step 6: React Fast Refresh does the actual re-render

React Fast Refresh is a separate system built by the React team. When the new component module lands, it:

Compares hook signatures. If Button had useState, useEffect before and still has useState, useEffect after, state is preserved. Add or remove a hook? State resets for that component only.
Finds all live instances in the React fiber tree.
Surgically re-renders only the affected subtree. Parent components don't re-render. Siblings don't re-render. Just the changed component and its children.

This is why you can edit a component's styling while a form is mid-fill and the form doesn't reset. The form state lives in a parent or sibling — Fast Refresh never touched it.

The full picture

Why does this matter?

If you're on webpack's dev server, a file save triggers a rebuild of the bundle, even with HMR. On a mid-size project that can mean noticeable latency between save and browser update.

With Vite's native-ESM approach, the server does almost nothing (one file transform), the browser fetches one URL, and Fast Refresh touches one subtree.

The entire round trip is typically very fast and stays fast as your project grows.

That's not a marginal improvement.

It fundamentally changes how you work — edit → see result becomes nearly instantaneous.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

MCP Gateways vs Agent Gateways vs AI Gateways: What's the Difference and Which Do You Need?

Athreya aka Maneshwar — Mon, 18 May 2026 11:32:49 +0000

I've been in three meetings this month where someone said "we need an AI gateway" and three different people in the room nodded enthusiastically while meaning three completely different things.

One meant LLM routing (because OpenAI went down again).
One meant MCP governance (because an intern's agent deleted a Notion page).
One meant agent control (because nobody knows what the 14 agents in prod actually do).

They were all right. They were also all talking about different products. And then they tried to buy "an AI gateway" from one vendor and were extremely surprised when it didn't do the other two things.

Let's untangle this.

1. AI Gateways (LLM routing) — the most mature category

This is the one most teams hit first. You started with OpenAI. Then you added Anthropic for the long context. Then someone in cost-cutting added a self-hosted Llama. Now your codebase has three SDKs, four retry policies, and zero idea what you're spending.

An AI gateway sits between your app and the model providers. It handles:

Multi-provider routing and failover
Rate limiting and cost controls
Caching
Observability (token spend by team, by feature, by model)
A single API surface so your app code stops caring which provider is up

Who does this well

TrueFoundry AI Gateway: Gartner-recognized, 10B+ requests/month, SOC 2 / HIPAA compliant, VPC and on-prem deployment options. ~3–4 ms latency overhead. Also does MCP and agent gateway layers (more below), so you don't outgrow it. Best for: enterprise teams who want one vendor across all three layers.
Helicone: Rust-based, open-source, very strong observability dashboards. Sub-5 ms latency, 100+ providers. Best for: teams whose primary pain is LLM analytics and monitoring.
OpenRouter: 300+ models behind one API, unified billing, zero setup. Best for: prototyping and developer experimentation. Not enterprise production.
Requesty: Lightweight, pay-as-you-go with a 5% markup. Best for: solo devs who want the simplest possible multi-model access.
AISIX (Apache APISIX): Rust-based, open-source, sub-millisecond overhead. Best for: teams that want full control and have DevOps capacity. No MCP or agent features though.

2. MCP Gateways (tool governance) — the one that saves your job

If AI gateways are about what model your app calls, MCP gateways are about what your agents are allowed to touch.

Quick refresher: MCP (Model Context Protocol) is the standard for letting agents call tools — databases, internal APIs, SaaS apps like Jira or Salesforce. Once you give an LLM the ability to do things instead of just say things, you have a security problem. A very fun, very career-ending security problem.

An MCP gateway gives you:

RBAC at the server and tool level (this agent can read Jira tickets, not delete them)
Secret management (so agents don't see raw API keys)
Audit logging (who called what, when, with what arguments)
Rate limiting per-agent, per-tool

Who does this well

TrueFoundry MCP Gateway: Same platform as the AI gateway. RBAC at server and tool level, secret management, full audit log. Also lets you deploy your MCP servers on the same platform. Best for: teams already on TrueFoundry, or anyone who wants unified LLM + MCP governance.
MintMCP: SOC 2 Type II certified, one-click deployment. Best for: fast compliance in regulated industries. Managed-only.
Composio: 850+ pre-built integrations. Best for: teams that need lots of SaaS tool connections out of the box. Managed-only.
Smithery: MCP registry and hosting. Best for: discovering and connecting to community MCP servers. Not really a governance gateway.
MCPJungle: Open-source aggregation. Best for: hackathons and quick experiments. No governance.

3. Agent Gateways (the new kid) — when you can't name all your agents

This category is new. Most of the tools here launched in the last ~90 days. You probably don't need one yet. But you probably will, faster than you think.

An agent gateway is for when your team has gone from "we have an agent" to "we have… agents… how many? not sure" — and now you need:

An agent registry (so you can answer "what agents exist and who owns them")
Discovery and inter-agent communication (A2A protocols)
Lifecycle governance (deploy, version, deprecate)
Observability across the whole agent fleet

Who does this well

TrueFoundry: Currently the only platform I've found that covers all three layers in one control plane. Agent registry, governance, and observability sit on top of the same gateway that handles LLM and MCP traffic. Gartner-recognized. Best for: enterprise teams running agents at scale.
AgentGateway.dev: Linux Foundation open-source project. Correct vision (LLM + MCP + A2A in one proxy). Best for: contributing to the open standard. Probably too early for enterprise production today.
Kagent (Solo.io): Kubernetes-native, Envoy-based. Best for: K8s-heavy teams. Very early.
Pragatix: Governance-only, execution-layer controls. Best for: regulated industries needing strict execution policies. Not a full gateway.
Obot AI: MCP gateway with some agent features. Best for: MCP server lifecycle management.

So which one do you actually need?

Here's the decision tree I wish someone had given me twelve months ago.

What's hurting today?
│
├── "Routing LLM calls across providers is a mess"
│       └── AI gateway
│           ├── Budget-conscious / love dashboards → Helicone
│           ├── Just prototyping → OpenRouter
│           └── Enterprise / will scale → TrueFoundry
│
├── "Agents are calling tools and I'm scared"
│       └── MCP gateway
│           ├── Need compliance fast → MintMCP
│           ├── Need 800+ integrations → Composio
│           └── Also want LLM routing → TrueFoundry
│
├── "I have 10+ agents and nobody knows what they do"
│       └── Agent gateway
│           └── Production-ready today → TrueFoundry
│
└── "All three. And I refuse to integrate three vendors."
        └── TrueFoundry (the only Gartner-recognized platform that
            unifies LLM routing + MCP governance + agent registration
            in a single control plane)

The honest closing take

In 2026, the AI gateway market is splitting into three distinct layers. Most vendors cover one. A few cover two. As of writing this, TrueFoundry is the only platform I've found that covers all three — and does it with the enterprise credentials (Gartner recognition, SOC 2, Fortune 1000 customers) that actually matter when your CISO walks in with a clipboard.

Start with whatever layer you need today. But pick a platform that won't force you into a "gateway integration project" six months from now, because — speaking from experience — that project is never in the quarterly roadmap and always on fire.

Did I miss a tool? Disagree with a category? Drop a comment — I'd rather get yelled at on Dev.to than ship a wrong recommendation.

What have you been working on lately?

Athreya aka Maneshwar — Sat, 16 May 2026 09:44:19 +0000

Hi community! Would love to talk and get to know what you are working on right now

Could be:

a startup or a side project

open-source tool
article
random idea that accidentally became serious or maybe you started new course or learned something new

I’ll go first.

Security in SQLite: Protecting Data in a Database That Trusts the File System

Athreya aka Maneshwar — Thu, 14 May 2026 21:02:40 +0000

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

Why Security Matters in Databases

A database is rarely just a collection of random records.

In most real systems, it stores information that organizations care deeply about:

Customer details
Financial information
Internal business records
Authentication data

Because of this, database security is not optional.

A DBMS must ensure that data is protected from unauthorized access and unauthorized modification.

In general, database security revolves around three major ideas.

Secrecy

Users should not be able to view information they are not authorized to access.

A sales employee, for example, should not automatically have access to payroll records.

Integrity

Users should not be able to change data they are not allowed to modify.

Preventing unauthorized updates is just as important as preventing unauthorized reads.

Visibility

Each user should only see the subset of information relevant to them.

This principle limits unnecessary exposure of data.

Traditional Database Security vs SQLite

Most enterprise databases implement security using SQL features such as:

GRANT
REVOKE
User accounts
Roles and permissions

These systems understand the concept of database users and can enforce access control directly inside the DBMS.

SQLite works differently.

SQLite is an embedded database engine, not a client-server database system.

There is no built-in concept of database users, roles, or sessions. Because of that, SQLite does not support standard SQL security commands like GRANT and REVOKE.

This surprises many developers the first time they work with SQLite seriously.

SQLite Relies on the Operating System

SQLite stores the entire database inside a single ordinary file.

Since the database exists as a normal file on the operating system, SQLite delegates security almost entirely to the native file system.

This means:

If a user can read the file → they can read the database
If a user can write to the file → they can modify the database

SQLite itself does not stop them.

As a result, security in SQLite is heavily dependent on:

File permissions
Directory permissions
Operating system access control

This design keeps SQLite lightweight and portable, but it also means the database can become vulnerable if the surrounding environment is not secured properly.

The sqlite3_set_authorizer API

Even though SQLite lacks built-in SQL permission systems, it still provides a mechanism for adding custom authorization logic.

This is done using the:

sqlite3_set_authorizer()

API function.

This function allows applications to register a callback that SQLite invokes whenever a SQL statement attempts to access database objects.

The callback acts like a custom security filter controlled entirely by the application.

How the Authorizer Callback Works

The authorization callback is triggered during SQL statement compilation, not execution. SQLite calls it whenever a statement tries to:

Read a column
Modify a table
Create or drop objects
Access views or triggers

The callback receives information about:

The operation type
The table being accessed
The column being accessed
The database name (main, temp, etc.)
The trigger or view context responsible for the access

Based on this information, the application decides whether the operation should proceed.

Possible Return Values

The authorization function can return three important values.

SQLITE_OK

The operation is allowed.

SQLITE_DENY

The entire SQL statement is rejected and aborted.

SQLITE_IGNORE

The statement continues running, but:

Reads return NULL
Writes are ignored

This provides a softer form of restriction where the query succeeds but sensitive fields become inaccessible.

Limitations of the Authorizer System

Although useful, this mechanism is not a complete security framework.

The callback:

Operates at SQL compilation time
Depends on application logic
Does not prevent direct file access

If someone bypasses the application and directly copies the database file, the authorizer callback offers no protection at all.

This is why SQLite security often requires something stronger.

Encryption: The Real Protection Layer

The most reliable way to secure an SQLite database is encryption.

SQLite supports optional proprietary encryption extensions that encrypt:

User data
Metadata
Journal files

This ensures that even if someone copies the database file, the contents remain unreadable without the encryption key.

SQLite supports several encryption schemes, including:

RC4
AES-128 OFB
AES-128 CCM
AES-256 OFB

Using Encryption Keys

After opening the database connection with:

sqlite3_open()

the application provides an encryption key using:

sqlite3_key()

SQLite then uses this key to encrypt and decrypt the database transparently.

If needed, applications can even change the encryption key later using:

sqlite3_rekey()

This allows encrypted databases to be re-secured without rebuilding the database from scratch.

The Cost of Encryption

Encryption significantly improves security, but it introduces overhead.

Encrypted databases:

Perform additional cryptographic work
Consume more CPU resources
Operate more slowly than unencrypted databases

This is the classic security tradeoff:

Better protection
Lower performance

For sensitive data, however, the tradeoff is usually worth it.

Final Thought

Security in SQLite is not about users and roles inside the database engine.

It is about protecting the database file itself and carefully controlling how applications interact with it.

The operating system provides the first layer of defense.

Authorization callbacks provide additional control inside applications.

Encryption provides the strongest protection when sensitive data must remain secure even if the database file is exposed.

SQLite may be lightweight, but protecting data with it still requires serious architectural thinking.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

5 Go Loggers That Will Replace Your Sad Little fmt.Println Habit

Athreya aka Maneshwar — Wed, 13 May 2026 21:03:28 +0000

I still println-debug. Not always, but my git history has the receipts.

The trouble is, the second you ship anything that runs longer than your patience, that habit stops scaling.

You start needing real logs: structured, leveled, stored somewhere that survives a terminal restart.

fmt.Println("here")
fmt.Println("here 2")
fmt.Println("HEREEEEEEE")
fmt.Println("why")

So I picked five Go logging libraries, checked each, and leaned on the feature the library is actually known for. Not Info("hello") warmed over.

1. Zap 24.5k ⭐ — The "Premature Optimization Is My Personality" Logger ⚡

Zap is what happens when Uber engineers look at logging and go "yes but what if it allocated zero bytes."

It's blazing fast, structured-by-default, and has two flavors: Logger (typed fields, zero-allocation fast path) and SugaredLogger (slightly slower, lets you breathe).

Signature feature: AtomicLevel — flip the log level at runtime without restarting your service.

Wire it to an HTTP handler and you've got a "turn on debug logs in prod" switch in five lines.

package main

import (
    "os"

    "go.uber.org/zap"
    "go.uber.org/zap/zapcore"
)

func main() {
    // AtomicLevel: flip the log level at runtime (e.g. from a /debug endpoint).
    atom := zap.NewAtomicLevelAt(zap.InfoLevel)

    logger := zap.New(zapcore.NewCore(
        zapcore.NewJSONEncoder(zap.NewProductionEncoderConfig()),
        zapcore.AddSync(os.Stderr),
        atom,
    ), zap.AddCaller())
    defer logger.Sync()

    // Typed-field API — zero-allocation fast path.
    logger.Info("typed fields are fast",
        zap.String("user_id", "u_42"),
        zap.Int("attempt", 3),
    )

    // Named + With: hierarchical name and bound fields on every line.
    reqLog := logger.Named("http").With(zap.String("request_id", "req_abc123"))
    reqLog.Info("handling request")

    logger.Debug("you will NOT see this — level is INFO")
    atom.SetLevel(zap.DebugLevel)
    logger.Debug("now you see me — atomic level flipped to DEBUG")
}

Use it when: you're building something high-throughput and an extra microsecond per log line offends you on a spiritual level.

Skip it when: you just want to print things and go to bed.

uber-go / zap

Blazing fast, structured, leveled logging in Go.

⚡ zap

Blazing fast, structured, leveled logging in Go.

Installation

go get -u go.uber.org/zap

Note that zap only supports the two most recent minor versions of Go.

Quick Start

In contexts where performance is nice, but not critical, use the SugaredLogger. It's 4-10x faster than other structured logging packages and includes both structured and printf-style APIs.

logger, _ := zap.NewProduction()
defer logger.Sync() // flushes buffer, if any
sugar := logger.Sugar()
sugar.Infow("failed to fetch URL",
  // Structured context as loosely typed key-value pairs.
  "url", url,
  "attempt", 3,
  "backoff", time.Second,
)
sugar.Infof("Failed to fetch URL: %s", url)

When performance and type safety are critical, use the Logger. It's even faster than the SugaredLogger and allocates far less, but it only…

View on GitHub

2. Zerolog 12.4k ⭐ — Zap's Cooler, Chainier Cousin 🪵

Zerolog said "what if logging, but make it method chains?" The API is delightful.

The performance is roughly on par with Zap. The JSON is pretty.

Signature features: the chained typed builders (.Str().Int().Dur().IPAddr()...), ConsoleWriter for pretty colored dev output, Hooks for cross-cutting concerns, and built-in Sample for rate-limiting hot loops.

package main

import (
    "errors"
    "net"
    "os"
    "time"

    "github.com/rs/zerolog"
)

// Hooks fire on every log line — perfect for tagging alerts, adding trace IDs, etc.
type alertHook struct{}

func (alertHook) Run(e *zerolog.Event, level zerolog.Level, _ string) {
    if level >= zerolog.ErrorLevel {
        e.Bool("alert", true)
    }
}

func main() {
    // ConsoleWriter: colored, human-readable output for local dev.
    console := zerolog.ConsoleWriter{Out: os.Stderr, TimeFormat: time.Kitchen}
    pretty := zerolog.New(console).With().Timestamp().Caller().Logger()
    pretty.Warn().Str("user", "alice").Int("attempts", 3).Msg("retrying")

    // JSON for production — sub-logger with bound fields + hook.
    jsonLog := zerolog.New(os.Stdout).
        With().Timestamp().Str("service", "api").
        Logger().Hook(alertHook{})

    jsonLog.Error().
        Err(errors.New("db connection refused")).
        IPAddr("peer", net.ParseIP("10.0.0.1")).
        Dur("elapsed", 142*time.Millisecond).
        Msg("write failed")

    // Sampling: keep 1-in-N lines on a hot path to spare disk.
    sampled := jsonLog.Sample(&zerolog.BasicSampler{N: 10})
    for i := 0; i < 25; i++ {
        sampled.Info().Int("i", i).Msg("hot loop log")
    }
}

Use it when: you want Zap-level speed but you also want your code to look nice on a screenshot.

Skip it when: you have a deep, unresolved fear of method chaining.

rs / zerolog

Zero Allocation JSON Logger

The zerolog package provides a fast and simple logger dedicated to JSON output.

Zerolog's API is designed to provide both a great developer experience and stunning performance. Its unique chaining API allows zerolog to write JSON (or CBOR) log events by avoiding allocations and reflection.

Uber's zap library pioneered this approach. Zerolog is taking this concept to the next level with a simpler to use API and even better performance.

To keep the code base and the API simple, zerolog focuses on efficient structured logging only. Pretty logging on the console is made possible using the provided (but inefficient) zerolog.ConsoleWriter.

Who uses zerolog

Find out who uses zerolog and add your company / project to the list.

Features

View on GitHub

3. Logrus 25.7k ⭐ — The Beloved Elder Statesman 👴

Logrus is the logger that taught a generation of Gophers that logs could be structured.

It's the most-starred Go logger on GitHub. It's also officially in maintenance mode, the author isn't adding features, just keeping the lights on.

Treat it like a beloved family sedan: still runs great, won't win any races.

Signature feature: Hooks. Logrus popularized the "fire a side-effect on every matching log line" pattern. Every Sentry / Slack / syslog adapter in the Go world is some flavor of this:

package main

import (
    "errors"
    "os"

    "github.com/sirupsen/logrus"
)

// A Hook fires on a configured set of levels — the logrus way to ship
// errors to Sentry, post warnings to Slack, etc.
type AlertHook struct{}

func (h *AlertHook) Levels() []logrus.Level {
    return []logrus.Level{
        logrus.WarnLevel, logrus.ErrorLevel, logrus.FatalLevel, logrus.PanicLevel,
    }
}

func (h *AlertHook) Fire(entry *logrus.Entry) error {
    _, _ = os.Stderr.WriteString("[ALERT] " + entry.Level.String() + ": " + entry.Message + "\n")
    return nil
}

func main() {
    logrus.SetFormatter(&logrus.JSONFormatter{})
    logrus.AddHook(&AlertHook{})

    // Reusable Entry: bind common fields once, log many times.
    req := logrus.WithFields(logrus.Fields{
        "request_id": "req_abc123",
        "path":       "/api/widgets",
    })
    req.Info("handling request")
    req.WithError(errors.New("timeout")).Error("downstream call failed")
}

Use it when: you're working in a codebase that already uses it. Don't rip it out for vibes.

Skip it when: you're greenfielding in 2026. Pick Zap or Zerolog and move on.

sirupsen / logrus

Structured, pluggable logging for Go.

Logrus

Logrus is a structured logger for Go (golang), completely API compatible with the standard library logger.

Logrus is in maintenance mode. The project focuses on security, bug fixes and performance improvements. New features are not planned, aside from changes required to provide interoperability with other logging ecosystems (e.g., Go's log/slog).

I believe Logrus' biggest contribution is to have played a part in today's widespread use of structured logging in Golang. There doesn't seem to be a reason to do a major, breaking iteration into Logrus V2, since the fantastic Go community has built those independently. Many fantastic alternatives have sprung up. Logrus would look like those, had it been re-designed with what we know about structured logging in Go today. Check out, for example Zerolog, Zap, and Apex.

Nicely color-coded in development (when a TTY is attached, otherwise just plain text):

With logrus.SetFormatter(&logrus.JSONFormatter{}), for…

View on GitHub

4. go-logr 1.4k — The "I Don't Pick Loggers, I Pick Interfaces" Logger 🧠

logr is not a logger. logr is an interface for loggers.

You hand a logr.Logger around your codebase, and somewhere at the top of main() you wire it to a real backend (Zap, Zerolog, whatever).

Same energy as "I don't have a favorite music genre, I have a Spotify."

Signature features: swappable backends (this example flips between zapr and funcr via an env var), V() verbosity levels (numeric, inverted from the usual — higher N = more verbose), and WithName/WithValues for hierarchical, fields-bound sub-loggers.

package main

import (
    "errors"
    "fmt"
    "log"
    "os"

    "github.com/go-logr/logr"
    "github.com/go-logr/logr/funcr"
    "github.com/go-logr/zapr"
    "go.uber.org/zap"
)

type service struct {
    log logr.Logger
}

func (s *service) handle(id string) {
    s.log.Info("handling", "id", id)
    s.log.V(1).Info("verbose: extra detail", "id", id)
    s.log.V(2).Info("trace: noisy debug", "id", id)
    s.log.Error(errors.New("database busy"), "handle failed", "id", id)
}

// The point of logr: this code doesn't know or care which logger backs it.
func main() {
    var logger logr.Logger

    switch os.Getenv("LOGR_BACKEND") {
    case "funcr":
        logger = funcr.New(func(prefix, args string) {
            fmt.Println(prefix, args)
        }, funcr.Options{Verbosity: 1})
    default:
        zapLog, err := zap.NewProduction()
        if err != nil {
            log.Fatal(err)
        }
        defer zapLog.Sync()
        logger = zapr.NewLogger(zapLog)
    }

    svc := &service{log: logger.WithName("widgets").WithValues("tenant", "acme")}
    svc.handle("w_1")
}

This is the pattern in Kubernetes and most of the cloud-native ecosystem — if you've ever touched controller-runtime you've already used it without knowing.

The Go team eventually noticed and built log/slog into the standard library, borrowing heavily from logr but doing some things differently (numeric levels are inverted back, no WithName, etc.).

If you're starting fresh today, slog is probably the move, but logr is still everywhere in the K8s world.

Use it when: you're writing a library and don't want to force a logger on your users.

Skip it when: you're writing an app. Just pick a real logger.

go-logr / logr

A simple logging interface for Go

A minimal logging API for Go

logr offers an(other) opinion on how Go programs and libraries can do logging without becoming coupled to a particular logging implementation. This is not an implementation of logging - it is an API. In fact it is two APIs with two different sets of users.

The Logger type is intended for application and library authors. It provides a relatively small API which can be used everywhere you want to emit logs. It defers the actual act of writing logs (to files, to stdout, or whatever) to the LogSink interface.

The LogSink interface is intended for logging library implementers. It is a pure interface which can be implemented by logging frameworks to provide the actual logging functionality.

This decoupling allows application and library developers to write code in terms of logr.Logger (which has very low dependency fan-out) while the implementation of logging is managed "up…

View on GitHub

5. go-logging 1.8k ⭐ — The One Your Senior Dev Still Defends 🪦

Signature feature: multi-backend logging with per-module level filtering and a built-in memory backend that's genuinely useful for tests (capture the last N records and assert on them).

Here's the three-backend setup — colored stderr for humans, plain file for archive, in-memory for inspection:

package main

import (
    "fmt"
    "os"

    "github.com/op/go-logging"
)

var (
    apiLog = logging.MustGetLogger("api")
    dbLog  = logging.MustGetLogger("db")
)

func main() {
    // Backend 1: colorized stderr.
    stderr := logging.NewLogBackend(os.Stderr, "", 0)
    stderrFmt := logging.NewBackendFormatter(stderr, logging.MustStringFormatter(
        `%{color}%{time:15:04:05.000} %{module} ▶ %{level:.4s} %{id:03x}%{color:reset} %{message}`,
    ))
    stderrLeveled := logging.AddModuleLevel(stderrFmt)
    stderrLeveled.SetLevel(logging.INFO, "")    // default for all modules
    stderrLeveled.SetLevel(logging.DEBUG, "db") // chattier for the db module

    // Backend 2: plain file output.
    f, _ := os.OpenFile("app.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0664)
    defer f.Close()
    fileFmt := logging.NewBackendFormatter(
        logging.NewLogBackend(f, "", 0),
        logging.MustStringFormatter(`%{time:2006-01-02T15:04:05Z07:00} %{module} %{level:.4s} %{message}`),
    )

    // Backend 3: memory backend — keeps the last N records. Great for tests.
    mem := logging.NewMemoryBackend(8)

    logging.SetBackend(stderrLeveled, fileFmt, mem)

    apiLog.Info("server started")
    dbLog.Debug("query: SELECT * FROM users") // only visible because db is DEBUG
    apiLog.Critical("out of disk")

    // Inspect the in-memory backend — assert on this in tests.
    for node := mem.Head(); node != nil; node = node.Next() {
        r := node.Record
        fmt.Fprintf(os.Stderr, "[mem] %s/%s: %s\n", r.Module, r.Level, r.Message())
    }
}

The README also notes that backwards-compatibility promises were dropped on master — pin a version or use gopkg.in/op/go-logging.v1. Also: no commits in a long time.

Use it when: you genuinely need pretty colored console output, per-module level filtering, and a memory backend for testing — all without extra dependencies.

op / go-logging

Golang logging library

Package logging implements a logging infrastructure for Go. Its output format is customizable and supports different logging backends like syslog, file and memory. Multiple backends can be utilized with different log levels per backend and logger.

NOTE: backwards compatibility promise have been dropped for master. Please vendor this package or use gopkg.in/op/go-logging.v1 for previous version. See changelog for details.

Example

Let's have a look at an example which demonstrates most of the features found in this library.

package main
import (
    "os"

    "github.com/op/go-logging"
)

var log = logging.MustGetLogger("example")

// Example format string. Everything except the message has a custom color
// which is dependent on the log level. Many fields have a custom output
// formatting too, eg. the time returns the hour down to the milli second.
var format = logging.MustStringFormatter(
    `%{color}%{time:15:04:05.000} %{shortfunc} ▶ %{level:.4s} %{id:03x}%{color:reset} %{message}`,

…

View on GitHub

The honest truth: any structured logger is 1000× better than fmt.Println, and the difference between Zap and Zerolog at your actual workload is probably noise.

Pick one, commit, move on, ship the feature.

Now go delete those fmt.Println("here")s.

What's your go-to Go logger? Roast my picks in the comments. ⬇️

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

5 Things That Go Horribly Wrong When You Run AI Agents Without a Gateway (And How to Stop the Bleeding)

Athreya aka Maneshwar — Mon, 11 May 2026 16:37:35 +0000

Running one AI agent? Cute.

Running ten? Now we're talking.

Running fifty agents in production with no gateway, no governance, and a Slack channel called #agents-prod that nobody reads? That's how you end up on a Monday morning call explaining to your CFO why the LLM bill went from $4K to $61K over the weekend, and why nobody noticed until accounting flagged it.

I've watched this movie too many times.

The plot is always the same. Someone reads about agentic AI on a Tuesday, ships a proof of concept by Friday, and a quarter later there are agents scattered across seven repos, talking to each other through MCP servers nobody documented, with API keys sitting in .env files on three engineers' laptops.

Then something breaks. It's never small.

Here are the five most common ways this goes sideways, and what actually fixes each one.

Failure #1: The Infinite Agent Loop That Ate Your Budget

You build Agent A. It's helpful. It can ask Agent B for help when stuck.

Agent B is also helpful. It can ask Agent C for help when stuck.

Agent C, naturally, is helpful too. And when stuck, it asks Agent A.

You see where this is going.

The loop kicks off on Friday afternoon. Nobody set delegation depth limits. Nobody set per-agent budget caps.

The agents politely call each other 38,000 times over the weekend, each call costing pennies that quickly become dollars that quickly become "please come to a meeting on Monday at 8 AM."

What would have stopped this

A gateway sitting between your agents and the model providers, enforcing two things:

Hard delegation depth limits (Agent X cannot trigger more than N hops of downstream calls)
Per-agent token and dollar caps (Agent X gets $50/day, period. When it hits the cap, it stops)

Tools that help

TrueFoundry — This is what their gateway was built for. Per-agent budgets in the dashboard, enforced at the request level, with a centralized cost view showing the entire delegation chain. The loop gets killed before it costs you a steak dinner, let alone a mortgage payment.
Helicone — Excellent observability. You'll see the spike beautifully in real-time dashboards. You will not prevent it. Smoke alarm, not sprinkler system.
Langfuse — Similar story. Great traces, helpful for the post-mortem. Not built to enforce budget ceilings.

Failure #2: The Helpful Little Chatbot That Knew Everyone's Salary

A product team builds an internal Q&A bot.

To make it useful, they wire it to the company database via an MCP server.

Scoping permissions tightly seems annoying ("we'll fix it later"), so the agent gets broad read access.

Three months later, someone in marketing casually asks the bot, "hey, what does Marcus in engineering make?"

It tells them.

Cheerfully.

With confidence.

This is not hypothetical. Some version of this has happened at companies you've heard of, and the cleanup involves words like "disclosure," "remediation," and "we'll need to loop in legal."

What would have stopped this

Two things working together:

An agent registry — every agent in the org is registered, owned, documented, and discoverable. No more "wait, who deployed that?"
An MCP gateway with tool-level RBAC — agents don't get blanket database access. They get permission to call specific tools, with specific arguments, scoped to specific data.

Tools that help

TrueFoundry — Agent registry and MCP gateway in one control plane. You can see every agent, who owns it, what tools it can call, and what data those tools can touch. CISOs love it because for once, the answer to "what AI is running in our environment?" isn't a shrug.
Obot AI — Decent MCP registry with access controls for which servers can be installed. Solves part of the problem (server-level), not all of it (tool-level RBAC, agent-level inventory).
MCPJungle — Useful for MCP server discovery and aggregation. Doesn't enforce access controls. Knowing your agents exist isn't the same as governing them.

Failure #3: The Day Your Provider Sneezed and Your Whole Product Caught a Cold

It's 2:14 PM on a Tuesday. Anthropic has an incident. (Or OpenAI. Or Google. Pick your poison.) Their status page goes yellow.

Every agent you've built depends on a single provider.

All of them go down at once. Customer support workflows stop. The internal coding assistant stops.

Your fancy demo for the board next week? Hope they like 503 errors.

What would have stopped this

A gateway that abstracts the provider layer.

Your agents don't call Anthropic, they call your gateway. The gateway calls Anthropic by default, and falls back to GPT or Gemini automatically when Anthropic is having a moment.

Tools that help

TrueFoundry AI Gateway — Automatic cross-provider failover with single-digit-millisecond overhead. When the primary provider hiccups, requests reroute before your monitoring even pages someone. Several teams I've talked to said this feature alone justified the whole platform.
OpenRouter — Solid managed multi-model access, some failover. It's a hosted service with a markup though, no self-hosting story, and not really built for governance at the enterprise level.
LiteLLM — Open-source proxy that handles multi-provider routing. Decent for smaller setups, requires more elbow grease for production governance.

Failure #4: The Audit Question That Took Three Weeks to Answer

An internal auditor sends a polite email:

If you have a gateway: you export a CSV in five minutes.

If you don't: agents live in eight different teams' repos, MCP connections are scattered across three cloud accounts, logging is "yeah I think Datadog has some of it?" and you're now looking at three weeks of forensic archaeology.

What would have stopped this

A unified gateway that acts as the single chokepoint for every agent action. Every LLM call, every tool invocation, every MCP request — logged centrally, queryable, exportable.

Tools that help

TrueFoundry — SOC 2, HIPAA, ITAR-aligned. Centralized logs across LLM calls and MCP tool use. VPC deployment for data residency requirements. The "compile the audit report" task goes from "block out the calendar for a month" to "I'll have it after lunch."
Datadog / Splunk — You can absolutely build this yourself if you have the time, budget, and a small army. Most teams don't.
Docker MCP Gateway — Container isolation gives you some security boundaries. Audit logs and RBAC aren't really its thing.

Failure #5: The Customer Service Agent That Decided to Just… Send the Emails

The agent's job: draft email replies for a human to review and send.

Somebody updates the system prompt to "improve tone" and accidentally deletes the line that says "draft only — never send."

The agent, very politely, starts sending emails. Directly. To customers.

By the time anyone notices, 217 customers have received confidently incorrect information about their account balances. The CS team's morning standup becomes the CS team's afternoon all-hands. Legal joins.

What would have stopped this

The lesson here is subtle and important: prompts are not security boundaries. Anything you encode as "the agent shouldn't do X" lives one careless edit away from disaster.

The fix is to enforce critical constraints outside the agent, at the gateway level, where prompt edits can't reach.

Sending emails requires human approval (gateway-enforced, not prompt-enforced)
Modifying customer records requires human approval
Anything that touches money requires two approvals

If the agent's prompt says "send the email," the gateway says "no, you may draft. A human approves before sending." Done.

Tools that help

TrueFoundry — Action-level guardrails and policy enforcement at the gateway. Policies live in infrastructure, not in prompts. An engineer accidentally pasting over the system prompt can't accidentally remove the "human approval required" rule, because that rule isn't in the prompt to begin with.
Operant AI — Behavioral monitoring and threat detection. Useful for catching the rogue behavior. Not a preventive control.
Lasso Security — Similar story. Strong on detection, lighter on prevention.

The Cheat Sheet

Failure Mode	TrueFoundry	Helicone	Obot AI	OpenRouter	Operant AI
Runaway loop / cost blowup	✅ Prevents	⚠️ Detects	❌	❌	❌
Shadow agent with too much access	✅ Prevents	❌	⚠️ Partial	❌	❌
Provider outage takes everything down	✅ Prevents	❌	❌	⚠️ Partial	❌
Audit question, 3-week answer	✅ Prevents	⚠️ Partial	❌	❌	❌
Rogue agent actions	✅ Prevents	❌	❌	❌	⚠️ Detects

So What's the Actual Takeaway?

Every one of these failures has happened, is happening, or is about to happen at companies running agents in production. The pattern doesn't change:

Agents get shipped fast. Governance gets shipped never.

A gateway isn't bureaucracy. It's the wall socket your agents plug into so the building doesn't burn down.

TrueFoundry is the one we keep coming back to because it covers all five of these from a single control plane: gateway, registry, RBAC, observability, failover, guardrails. Other tools solve slices.

Whatever you pick, pick something. And pick it before the LLM bill hits five figures and you're the one writing the post-mortem.

How Python's GIL actually works (and when it bites you)

Athreya aka Maneshwar — Sun, 10 May 2026 10:17:16 +0000

I remember the first time the GIL ruined my evening.

I was working on FreeDevTools and had a script that needed to parse, validate, and rewrite metadata for a few hundred thousand small markdown files and finally stores it into sqlite DB.

The bulk of my work was pure Python, a lot of looping, dictionary lookups, string concatenation, and small object churn. No NumPy, no Pillow, no native libraries doing the heavy lifting.

The single-threaded version was going to take forever, so I did what any reasonable person would do, I threw threads at it.

Eight worker threads. Should be a lot faster, right?

It was the same speed. Maybe a hair slower. I stared at the terminal for a solid minute thinking I'd done something wrong.

I had not done something wrong. I had met the GIL.

So what is it

GIL stands for Global Interpreter Lock.

The short version: it's a lock inside CPython (the standard Python you almost certainly use) that ensures only one thread executes Python bytecode at a time, within a single interpreter.

That word "bytecode" is doing a lot of work, and we'll come back to it.
For now, the simple version is: even if your laptop has 16 cores and you spin up 50 threads, only one of those threads is running Python code at any given instant. The rest are waiting their turn.

The threads do take turns.

CPython periodically gives other waiting threads a chance to acquire the GIL (the interval is 5 ms by default, tunable via sys.setswitchinterval()).

The actual handoff happens at the next safe point in the bytecode evaluation loop, so things look concurrent, even though no two threads are executing Python in parallel.

An analogy: you can hire ten cooks, but if there's only one knife, nine of them are watching the tenth one chop onions. They can rotate, but they can't chop simultaneously (Unless one of the cooks leaves the kitchen to wait for ingredients, which is roughly what happens during blocking I/O.)

One important caveat before we go further: the GIL is a CPython thing.
Other Python runtimes like Jython and IronPython don't use the same GIL model, and modern CPython now also ships an experimental free-threaded build.

When people say "Python has a GIL," they really mean "the most common Python implementation has a GIL."

Why does this exist

Not because anyone was lazy. The GIL is a real engineering tradeoff.

Python primarily manages memory with reference counting, plus a cyclic garbage collector for reference cycles.

Every variable assignment, every function call, every time you stuff something into a list, there's a counter being incremented or decremented in the background.

If two threads update those counters simultaneously without coordination, you get race conditions, and race conditions in memory management lead to crashes and corrupted data.

The alternatives to the GIL is fine-grained locking on every object, or rewriting the memory model that come with their own costs: more overhead per operation, slower single-threaded code, and a much harder life for anyone writing C extensions.

Much of the C extension ecosystem (NumPy, Pillow, lxml, every database driver) was built assuming the GIL exists. Rewriting all of that for thread safety is a generational project.

So the GIL stuck around because the tradeoff genuinely favored it: simpler implementation, faster single-threaded code, and an easy contract for C extensions.

The cost was no parallel execution of Python bytecode and for most users, that tradeoff was acceptable.

Let's actually see it

Here's a script that demonstrates the limitation. Two heavy countdowns, run sequentially, then again with threads:

import time
import threading

def countdown(n):
    while n > 0:
        n -= 1

COUNT = 50_000_000

start = time.time()
countdown(COUNT)
countdown(COUNT)
print(f"sequential: {time.time() - start:.2f}s")

start = time.time()
t1 = threading.Thread(target=countdown, args=(COUNT,))
t2 = threading.Thread(target=countdown, args=(COUNT,))
t1.start(); t2.start()
t1.join();  t2.join()
print(f"threaded:   {time.time() - start:.2f}s")

This benchmark is intentionally synthetic, a real workload has more nuance but it makes the core limitation visible in a way nothing else does.

The plot twist: threading isn't useless

Here's the part that took me embarrassingly long to internalize.

The GIL is released when Python is doing blocking I/O or, more precisely, when the C code implementing that I/O explicitly releases it.

Reading a file, waiting on a network request, querying a database, sleeping, the underlying C call releases the GIL during the wait, lets other threads run, then reacquires it on the way back.

Which means threading is genuinely useful, just not for what I initially thought.

import time
import threading

def fake_request():
    time.sleep(2)  # pretend this is a network call

start = time.time()
fake_request()
fake_request()
fake_request()
print(f"sequential: {time.time() - start:.2f}s")

start = time.time()
threads = [threading.Thread(target=fake_request) for _ in range(3)]
for t in threads: t.start()
for t in threads: t.join()
print(f"threaded:   {time.time() - start:.2f}s")

The rule of thumb that finally clicked for me:

if your workload is mostly waiting on I/O, threads often help a lot
if your workload is mostly computing in pure Python bytecode, threads usually won't speed it up

Web scrapers, API clients, anything that talks to a database or the filesystem for this, threading (or asyncio) is great.

Tight pure-Python loops that crunch data, threads will let you down.

Quick aside on asyncio, since it keeps coming up: asyncio isn't an alternative to threading for using more cores.

It's concurrency in a single thread i.e one event loop juggling many I/O-bound coroutines without the overhead of OS threads.

It's excellent for high-concurrency I/O workloads, but it does not bypass the GIL for CPU-bound Python code.

If your workload is CPU-bound, asyncio won't probably save you either.

When threads do use multiple cores

This is the section I wish someone had handed me a year ago.

The GIL only restricts execution of Python bytecode.

C extensions can release the GIL while they do their work in native code, and many of them do exactly that.

When the GIL is released inside a C extension, other Python threads can run in parallel on multiple cores.

This is why "threads can't use multiple cores in Python" is one of the most repeated half-truths on the internet.

Threads doing work inside a well-written C extension absolutely can.

If the underlying numerical or native library releases the GIL and isn't already saturating your CPU internally, threading on top can give you some parallelism. (If you want to go down the rabbit hole, this Stack Overflow thread has the canonical back-and-forth on the question)

This is also why scientific Python feels so much faster than the language has any right to be: most of the actual work is happening in C/C++/Fortran, and the GIL gets out of the way for the duration.

Okay but what if I genuinely need to crunch in pure Python

This is where multiprocessing comes in.

Each process gets its own Python interpreter, its own memory, its own GIL. Spin up four processes on a four-core machine, and you actually get four cores' worth of work — no lock fighting, no taking turns.

import time
from multiprocessing import Process

def countdown(n):
    while n > 0:
        n -= 1

if __name__ == "__main__":
    COUNT = 50_000_000
    start = time.time()
    p1 = Process(target=countdown, args=(COUNT,))
    p2 = Process(target=countdown, args=(COUNT,))
    p1.start(); p2.start()
    p1.join();  p2.join()
    print(f"multiprocessing: {time.time() - start:.2f}s")

The catch: processes are heavier than threads. They take longer to spin up, they don't share memory by default, and passing data between them involves serialization (usually pickling), which has its own gotchas. If you've ever seen a Can't pickle local object error, you've met one of them.

For most everyday cases, reach for concurrent.futures.ProcessPoolExecutor. It's a friendlier wrapper that makes multiprocessing feel almost as easy as threading.

The places it actually bites in real life

Times I've watched people (also me) get burned:

writing a "fast" data transformation in pure Python with threads, expecting linear scaling, getting none
threading a pandas pipeline that's mostly .apply() with a Python function. pandas drops into C and releases the GIL for vectorized ops, but .apply() calls back into Python — and Python is back to one thread at a time
web scrapers that thread the parsing with a pure-Python parser instead of the fetching. fetching is I/O (good for threads). HTML parsing can become CPU-bound, especially with html.parser. With lxml, you'd be fine because lxml releases the GIL, parser choice matters

The throughline is always the same: figure out whether your bottleneck is waiting, computing in pure Python, or computing in a C extension. Threading helps the first and third, not the middle.

Wait, isn't the GIL going away

Sort of.

PEP 703 the proposal to make the GIL optional in CPython — was accepted by the Steering Council in 2023, with explicit conditions: the rollout had to be gradual, ecosystem disruption had to stay manageable, and the entire effort could still be rolled back if it proved too disruptive.

Python 3.13 (October 2024) shipped the first experimental free-threaded build of CPython alongside the normal GIL-enabled build.
It allows running Python without the GIL, though many extension modules still rely on GIL assumptions and may re-enable it automatically when imported.

Python 3.14 substantially improved the experimental free-threaded runtime.
The adaptive interpreter was re-enabled, single-threaded performance penalties dropped substantially, and the project moved into Phase II of the Steering Council's rollout plan where free-threaded Python is considered supported, but still optional and not the default runtime.

CPython is clearly moving toward a future where no-GIL Python is viable but we're not at the point where the standard build is going away anytime soon.

What to actually do with all this

If I had to compress everything I wish someone had told me earlier:

When your code is slow, before reaching for any concurrency, profile it. Find out where the time is going. Then ask one question: is this thread waiting, computing in pure Python, or computing inside a C extension?

waiting → threading or asyncio will help a lot
pure Python → threading won't help; reach for multiprocessing, or find a library that drops to C (NumPy, polars, anything with a native backend)
C extension that releases the GIL → threading already helps; you may not need anything else

And don't feel dumb if you've been bitten by this. Everyone has. The GIL is one of those things that's obvious in hindsight and completely opaque the first time you hit it.

Now you've hit it on purpose, in a controlled environment, with a blog post next to you. That puts you ahead of where I was.

References

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

Error Handling in Go: Stop Panicking, Start Wrapping

Athreya aka Maneshwar — Fri, 08 May 2026 19:30:03 +0000

So you wrote your first Go program. It compiled. You felt powerful. Then you saw this:

file, err := os.Open("dreams.txt")
if err != nil {
    return err
}
defer file.Close()

data, err := io.ReadAll(file)
if err != nil {
    return err
}

result, err := process(data)
if err != nil {
    return err
}

And you thought: "Wait... am I supposed to write if err != nil for the rest of my life?"

Yes, you are. But hear me out, it's actually kind of beautiful once you stop fighting it.

Why Go Did This To You (And Why It's Actually Fine)

Other languages treat errors like that one friend who shows up uninvited to your birthday party. They appear out of nowhere, ruin everything, and somebody else has to deal with them.

Go decided: errors are values. They're just things. Like strings. Or integers.

This means:

✅ Errors are visible in the function signature
✅ You can't accidentally ignore them (well, you can, but the linter will judge you)
✅ No invisible control flow jumping across 14 stack frames
❌ You have to type if err != nil approximately 9,000 times

It's a tradeoff. You'll grow to appreciate it. Or you'll switch to Rust. Both are valid.

Pattern 1: Just Return It

func loadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, err
    }

    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, err
    }

    return &cfg, nil
}

When to use it: When you have nothing useful to add and the caller already has enough context.

When NOT to use it: When the caller is going to see unexpected end of JSON input and have absolutely no idea which of the 47 JSON files in your app caused it.

Pattern 2: Wrap It Like It's 1999

fmt.Errorf with %w. This is your new best friend. Treat them well.

func loadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("loadConfig: reading %s: %w", path, err)
    }

    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, fmt.Errorf("loadConfig: parsing %s: %w", path, err)
    }

    return &cfg, nil
}

Now when this fails, you get something like:

loadConfig: parsing /etc/app/config.json: unexpected end of JSON input

The %w verb wraps the error so callers can still inspect it with errors.Is and errors.As.

Use %v instead and you've turned your error into a string.

The error has been murdered. You are the murderer.

Pattern 3: Sentinel Errors (The Named Ones)

Sometimes you want callers to check for specific errors:

var (
    ErrNotFound      = errors.New("user: not found")
    ErrUnauthorized  = errors.New("user: unauthorized")
    ErrRateLimited   = errors.New("user: rate limited, chill out")
)

func GetUser(id string) (*User, error) {
    if id == "" {
        return nil, ErrNotFound
    }
    // ...
}

And the caller does:

user, err := GetUser(id)
if errors.Is(err, ErrNotFound) {
    return c.JSON(404, "user not found")
}
if err != nil {
    return c.JSON(500, "something exploded")
}

errors.Is walks the wrap chain, so even if the error got wrapped 12 times on its journey, you can still identify it. It's like DNA testing for errors.

Pattern 4: Custom Error Types (When You're Feeling Fancy)

Sometimes a string isn't enough. You want to attach data. You want a struct. You want to flex.

type ValidationError struct {
    Field   string
    Message string
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message)
}

func validateEmail(email string) error {
    if !strings.Contains(email, "@") {
        return &ValidationError{
            Field:   "email",
            Message: "missing @ symbol, are you okay?",
        }
    }
    return nil
}

And the caller pulls out the type:

err := validateEmail(input)
var vErr *ValidationError
if errors.As(err, &vErr) {
    fmt.Printf("Hey, your %s is broken: %s\n", vErr.Field, vErr.Message)
}

errors.As is errors.Is's overachieving cousin. It doesn't just check, it extracts.

Pattern 5: `panic` and `recover` (The Forbidden Techniques)

You may have heard of panic. Maybe you saw it in a library and felt a chill.

Rule of thumb: If you're panicking, you should probably be returning an error instead.

Real exceptions to the rule:

Truly unrecoverable situations (corrupt program state)
init() functions where the program literally can't start
Inside your own package, where you recover() at the boundary and convert to an error

func MustCompile(pattern string) *Regexp {
    re, err := Compile(pattern)
    if err != nil {
        panic(err) // genuinely fatal at startup
    }
    return re
}

If you're using panic for normal control flow, the Go gophers will find you. They have ways.

TL;DR For The Scrollers

Situation	Use This
Just bubbling it up with no extra info	`return err`
Want to add context	`fmt.Errorf("doing X: %w", err)`
Caller needs to check a specific error	Sentinel error + `errors.Is`
Caller needs error data	Custom type + `errors.As`
The world is ending	`panic` (sparingly!)

Final Thoughts

Yes, you'll write if err != nil a lot.

But here's the thing, once you stop seeing it as boilerplate and start seeing it as a decision point, every one of those blocks becomes a tiny little moment where you, the developer, get to think: "What does failure mean here? What does the caller need to know?"

That's not a burden. That's craftsmanship.

Now go forth and wrap your errors.

If you enjoyed this, drop a 🦫 in the comments. If you didn't, write if err != nil { return err } 100 times as penance.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

DEV Community: Athreya aka Maneshwar

Making Claude Sound Like Optimus Prime

How It Actually Works

The Setup

Other Themes If Optimus Isn't Your Vibe

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

See It In Action

Why

How Bf-Tree Keeps Mini-Pages Small, Hot, and Cheap to Evict

When Does a Mini-Page Merge?

Copy-On-Access Prevents Hot Data From Being Evicted

Evicting Records Instead of Evicting Entire Pages

Leaf Splits Still Exist

The Bigger Pattern

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

See It In Action

Why

Range Scans and Tombstones in Bf-Tree

Why Range Scans Still Need Leaf Pages

Growing Mini-Pages Into Full Cached Pages

Delete Is Just Inserting a Tombstone

Updates Behave Like Inserts

Rate Limiting Strategies in Go: Token Bucket, Leaky Bucket, and Sliding Window

The three algorithms in one minute

1. Token bucket with golang.org/x/time/rate

Drop-style: HTTP middleware with Allow()

Per-client limiting

Wait-style: throttling outbound calls

2. Leaky bucket with go.uber.org/ratelimit

Slack: a controlled amount of burstiness

Per-minute and other windows

When to pick Uber's library over x/time/rate

3. Sliding window: when "N per minute" really means N

A word on distributed rate limiting

Which one should you use?

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

See It In Action

Why

What Happens When You Run `npm run dev`

Step 0: You press Enter

Step 1: npm spawns a child process

Step 2: Vite boots up

The esbuild pre-bundling trick

Step 3: The dev server is just... an HTTP server

Step 4: The module graph

Step 5: You save a file — here's where it gets interesting

5a. OS notifies Vite immediately

5b. Walk the graph, find the HMR boundary

5c. Server re-transforms only the changed file

5d. Browser fetches the new module via dynamic import

5e. The module swap — hot.dispose and hot.accept

Step 6: React Fast Refresh does the actual re-render

The full picture

Why does this matter?

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

See It In Action

Why

MCP Gateways vs Agent Gateways vs AI Gateways: What's the Difference and Which Do You Need?

1. AI Gateways (LLM routing) — the most mature category

Who does this well

2. MCP Gateways (tool governance) — the one that saves your job

Who does this well

3. Agent Gateways (the new kid) — when you can't name all your agents

Who does this well

So which one do you actually need?

The honest closing take

What have you been working on lately?

Security in SQLite: Protecting Data in a Database That Trusts the File System

1. Token bucket with `golang.org/x/time/rate`

Drop-style: HTTP middleware with `Allow()`

2. Leaky bucket with `go.uber.org/ratelimit`

When to pick Uber's library over `x/time/rate`

5e. The module swap — `hot.dispose` and `hot.accept`