if you’ve been thinking about subscribing, this is the best time to join. We wanted to give a 50% discount until the end of summer.

You may ask, why not all articles are free? We start publishing them as free and limit the older ones so LLMs don’t train on them such easily.

Our goal remains the same: publish practical, high-quality engineering content that helps you become a better software engineer.

As a paid subscriber, you’ll get:

• Two hands-on technical articles every month.

• Full access to our entire archive of paid content.

• Access to our private Discord, where you can chat directly with the writers.

• The opportunity to suggest topics and help shape what we publish next.

If that sounds like something you’d enjoy, we’d love to have you in the community.

JOIN

Best,

Alex, Julien

I genuinely like the project. The interface is clean, fast, and consistent. Unlike ecosystems such as npm, package authors don’t need to explicitly publish documentation anywhere—if your module is available through the Go module ecosystem, it’s already indexed.

The documentation is generated directly from source code downloaded via the Go Module Mirror, making it one of the most seamless documentation systems around.

For example, I maintain a PayPal SDK for Go, and it’s automatically available on pkg.go.dev without any extra publishing step.

https://pkg.go.dev/github.com/plutov/paypal/v4

Recently, the Go team took this one step further by launching the pkg.go.dev API.

Instead of scraping HTML or reverse-engineering the website, we now have direct programmatic access to package metadata, module versions, symbols, vulnerabilities, import relationships, and much more.

Even better, the API is published with an official OpenAPI specification.

https://pkg.go.dev/v1beta/openapi.yaml

That seemingly small detail changes everything. It means generating a Go client becomes almost effortless.

Why I Care

I spend most of my day inside Neovim.

Every time I need to open a browser just to look up package documentation, it breaks my flow. Switching contexts sounds insignificant until you do it dozens of times every day.

The new API finally makes it practical to browse Go documentation entirely from the terminal.

So I decided to build a small TUI (terminal UI) that lets me:

• search packages

• browse module versions

• inspect exported symbols

• extend it later with vulnerabilities, dependency information, and more

all without leaving the terminal.

Here is what’s we’re going to build:

Sponsor

AI writes more code than ever. Reviewing it shouldn’t mean scrolling forty files in alphabetical order.

CodeRabbit Review reorganizes any pull request from a flat file list into a structured, layer-by-layer walkthrough - the logical reading order of the change, not the order your platform happens to sort it. Every range gets its own plain-language summary, with sequence diagrams, state machines, and ERDs generated inline wherever a visual earns its place.

Cohorts group related files and chunks so you review one idea at a time. Layers order them so foundational changes - data shapes, contracts - come before the code that depends on them. Code Peek lets you click any variable, function, class or type to see its definition and usages without leaving the tab, while Semantic Diff view cuts past formatting noise to show what actually changed.

Open it straight from the Review Change Stack button in the PR Walkthrough. Navigate cohorts and layers from the keyboard, comment against exact line ranges and submit native reviews, comments and approvals post back to GitHub or GitLab right where your team expects them.

In the early access, available for free to everyone.

From the team that pioneered AI code reviews. 2M reviews every week. 6M repos. 15K customers.The review interface built for the way modern PRs are actually written.

Review your next PR with CodeRabbit Review Today

Exploring the API

The API exposes structured metadata through a collection of REST endpoints.

Some of the most useful ones are:

• /search

• /package

• /module

• /versions

• /symbols

• /imported-by

• /vulns

Everything is read-only and designed to be cache-friendly.

For example, retrieving metadata for the cmp package is as simple as:

curl https://pkg.go.dev/v1beta/package/github.com/google/go-cmp/cmp | jq

The response includes information such as:

• module path

• package path

• version

• synopsis

• redistributable status

The important part isn’t the JSON itself.

The important part is that we can now build tools on top of Go’s package ecosystem without scraping a single HTML page.

Generating an API Client

Since the API publishes an OpenAPI schema, generating a Go SDK is straightforward using oapi-codegen by Jamie Tanna.

https://github.com/oapi-codegen/oapi-codegen

I’ve previously made a video about oapi-codegen, so this project was a perfect excuse to use it again.

go install github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@latest

oapi-codegen \
  -generate types,client \
  -package pkgsiteapi \
  pkgsiteapi/openapi.yaml > pkgsiteapi/client.gen.go

There was one small catch.

At the time I built this project, generating directly from the published OpenAPI URL didn’t work. The document itself contained a couple of issues:

• some {path} endpoints were missing their corresponding path parameter definitions

• one schema reference was invalid
  

My workaround was simple: download the specification, fix the issues locally, and generate the client from that file instead.

I also noticed that some response types aren’t fully modeled. For example, the /search endpoint doesn’t map directly to a dedicated SearchResult type, so I had to extend the generated models myself.

Nothing impossible, but there is definitely room for improvement.

Building the TUI

For the interface I used Bubble Tea, which has become my default choice for terminal applications.

The application itself is intentionally minimal.

There are three areas of focus:

• Search input

• Search results

• Package details

The model keeps track of the currently selected package along with the API responses.

ype Model struct {
    client *pkgsiteapi.ClientWithResponses

    input    textinput.Model
    viewport viewport.Model

    results  []pkgsiteapi.SearchResult
    currItem *pkgsiteapi.SearchResult

    versions *pkgsiteapi.PaginatedResponse
    symbols  *pkgsiteapi.PackageSymbols

    loading bool
    focus   focusMode
}

Bubble Tea’s architecture fits this kind of application nicely.

The UI reacts to messages:

• a search completes

• package details arrive

• an error occurs
  

The Update() function becomes the event loop that coordinates everything, while the API calls live separately in commands.go.

The result is a clean separation between:

• state

• networking

• rendering
  

which makes the application easy to extend later.

Btw, there is also a video me explaining the details of Bubble Tea.

Putting Everything Together

The entry point is pleasantly small.

After creating the generated API client, Bubble Tea takes over.

client, err := pkgsiteapi.NewClientWithResponses(apiBaseURL)

if _, err := tea.NewProgram(
    newModel(client),
    tea.WithAltScreen(),
).Run(); err != nil {
    ...
}

Most of the complexity ends up living in the update loop rather than in main.go, which is exactly where it belongs.

Where This Can Go Next

The current application only scratches the surface of what’s available.

Because the API already exposes module versions, symbols, dependency information, and vulnerabilities, it wouldn’t take much to add features like:

• vulnerability browsing

• dependency trees

• reverse dependency lookup

• package bookmarking

• offline caching

• fuzzy search

• documentation previews

The hard part—accessing structured package data—is already solved by the Go team.

Final Thoughts

I think this API is one of the more exciting additions to the Go tooling ecosystem in recent years.

It removes the need for scraping, provides an official machine-readable interface, and makes building editor plugins, terminal tools, dashboards, and automation dramatically easier.

I’m already using my terminal package browser daily, and it saves me from constantly switching to the browser while working in Neovim.

If you’re building developer tooling for Go, this API is definitely worth exploring.

Thanks to the Go team for making it available.

Resources

• CodeRabbit Review

• Source code for this project

• pkg.go.dev

• Go Module Mirror

• Introducing the pkg.go.dev API

• OpenAPI specification

• Discuss on Hacker News

Sponsored by CodeRabbit — but this is a real PR, on a real codebase, with real findings. I’m going to show you exactly what the tool caught, what it got wrong, and whether the “AI reviews your PR” pitch holds up when the PR is 218 files and minus‑74,096 lines.

AI writes more code than ever. Reviewing it shouldn’t mean scrolling forty files in alphabetical order.

CodeRabbit Review reorganizes any pull request from a flat file list into a structured, layer-by-layer walkthrough - the logical reading order of the change, not the order your platform happens to sort it. Every range gets its own plain-language summary, with sequence diagrams, state machines, and ERDs generated inline wherever a visual earns its place.

Cohorts group related files and chunks so you review one idea at a time. Layers order them so foundational changes - data shapes, contracts - come before the code that depends on them. Code Peek lets you click any variable, function, class or type to see its definition and usages without leaving the tab, while Semantic Diff view cuts past formatting noise to show what actually changed.

Open it straight from the Review Change Stack button in the PR Walkthrough. Navigate cohorts and layers from the keyboard, comment against exact line ranges and submit native reviews, comments and approvals post back to GitHub or GitLab right where your team expects them.

In the early access, available for free to everyone.

From the team that pioneered AI code reviews. 2M reviews every week. 6M repos. 15K customers.The review interface built for the way modern PRs are actually written.

Review your next PR with CodeRabbit Review Today

The setup: killing a feature that outgrew the game

HiddenWars is a browser-based hacking strategy game — Go + Echo on the backend, Svelte 5 on the frontend, PostgreSQL, Redis.
The Corruption War was a cooperative map/season meta-game that had accumulated ~74k lines of code and too many design docs. It was time for it to go.

218 files changed · +1,453 / −74,096 · 5 phases · one SQL migration

This is the worst-case input for an automated reviewer. Most of the diff is deletions, the codebase has a genuinely confusing naming collision (more on that in a minute), and the “interesting” changes are surgical edits buried inside shared files. If a tool can produce a useful review here, it can produce one anywhere.

I installed CodeRabbit on the repo, pointed it at the PR, set the profile to Chill (the balanced middle option — more on the three profiles later), and let it run.

What follows is a look at what it caught on the Go specifically, what it got wrong, and whether the “AI reviews your PR” pitch holds up when the PR is 218 files.

The hard part: a Go interface that mixed two systems

The single gnarliest file was backend/internal/db/botnets.go. It defins a repository interface that he botnet subsystem hangs off:

type BotnetRepository interface {
	ListPlayerNodes(ctx context.Context, playerID string, limit, offset int, filter NodeListFilter) ([]models.PlayerNode, int, error)
	// ... healthy, degraded, corrupted node management ...

	// Siphon-scoped locking: pins draining nodes to a specific session so
	// concurrent siphons keep separate draining pools.
	LockNodesForSiphon(ctx context.Context, playerID, slug string, count int, sessionID string) (int, error)
	UnlockNodesBySiphonSession(ctx context.Context, playerID, sessionID string) error

	// War-op-scoped locking: pins healthy/degraded nodes of slug to a hack op as
	// 'war_committed' (ownership via war_op_id). Returns the locked node IDs.
	LockNodesForWarOp(ctx context.Context, playerID, slug string, qty int, opID string) ([]string, error)

	// UnlockWarOpNodes reverts the player's surviving war_committed nodes for opID ...
	UnlockWarOpNodes(ctx context.Context, playerID, opID string) error

	// LiveOpComposition returns the current surviving committed composition per
	// player for an op: counts only nodes still state='war_committed'.
	LiveOpComposition(ctx context.Context, opID string) (map[string]models.NodesComposition, error)
	LiveOpDegraded(ctx context.Context, opID string) (map[string]map[string]int, error)
	LiveOpAbsorbers(ctx context.Context, opID string) (map[string]map[string][]models.PlayerNode, error)

	// DegradeWarOpNodesTracked damages up to maxCount of the player's war_committed
	// nodes of slug pinned to opID, using the hack damage model ...
	DegradeWarOpNodesTracked(ctx context.Context, playerID, opID, slug string, maxCount int, damage, corruptThreshold float64) (int, []models.NodeDamageEntry, error)

	// ... raid, bounty, siphon, mining, signature counts ...
}

The trap is the word corruption. This interface, and this whole file, contains *two unrelated mechanics*:

- The Corruption War — the `WarOp` / `LiveOp` methods above, the `war_committed` node state. This is what I’m deleting.

- Node corruption — `corrupted` nodes, corruption *spread*, the `corruption_immunity` buff. A separate botnet maintenance mechanic that stays.

A reviewer — human or AI — that confuses those two will either delete the wrong code or drown you in false “you’re removing the wrong thing!” comments. I was specifically watching for how CodeRabbit handled it.

The Go that needed surgery, not deletion

The war methods came out cleanly — eight method signatures deleted from the interface, eight implementations deleted below. The subtle work was the *other* Go in the file: methods that stay, but whose raw SQL references war states inline. Take `SeverNodes`:

func (b *Botnets) SeverNodes(ctx context.Context, playerID string, nodeIDs []string) (int, error) {
	if len(nodeIDs) == 0 {
		return 0, nil
	}
	conn := b.Acquire()
	defer conn.Release()

	rows, err := conn.Query(ctx, `
		DELETE FROM player_nodes
		WHERE id = ANY($1)
		  AND botnet_id = (SELECT id FROM botnets WHERE player_id = $2)
		  AND state NOT IN ('locked', 'committed', 'raid_committed', 'war_committed', 'region_recon',
		                    'boss_committed', 'hashing', 'draining', 'recompiling')
		RETURNING id
	`, nodeIDs, playerID)
	// ...
}

war_committed and region_recon in that NOT IN list are war coupling — they have to come out. But ’locked’, ’committed’, ’raid_committed’, ’corrupted’ (further up) all stay, because those are raid/bounty/node-corruption mechanics. This is raw SQL *as a Go string literal*: your compiler will not help you. There is no type checker that catches a stray ’war_committed’ left in a query. This is exactly where an AI reviewer earns its keep — if it can read the SQL.

CodeRabbit did. It never flagged the legitimate states, and it correctly identified every war-coupled string across the file. The naming collision it had to reason through: *this corrupted is the keep-mechanic, that war_committed is the delete-mechanic.* It inferred the distinction from context. That’s the moment I stopped thinking of it as a linter.

The same pattern, in a 60-line reaper query

Where it got genuinely impressive was ReleaseOrphanedLockedNodes — a background reaper that’s one big CTE with a UNION per node state. Each arm reaps nodes stuck in a transient state (locked, committed, hashing, draining) when their owning op/session has vanished. The war removal meant: delete the war_committed arm entirely, but leave the raid/bounty/siphon/decryption arms alone. The surviving query looks like this (trimmed for length):

func (b *Botnets) ReleaseOrphanedLockedNodes(ctx context.Context) (int64, error) {
	conn := b.Acquire()
	defer conn.Release()
	tag, err := conn.Exec(ctx, `
		WITH orphaned AS (
			-- committed nodes whose raid is completed
			SELECT pn.id FROM player_nodes pn
			JOIN botnets bot ON bot.id = pn.botnet_id
			WHERE pn.state IN ('committed', 'raid_committed')
			  AND pn.locked_at IS NOT NULL
			  AND NOT EXISTS (
			    SELECT 1 FROM raid_registrations rr
			    JOIN raids r ON r.id = rr.raid_id
			    WHERE rr.player_id = bot.player_id AND r.completed_at IS NULL
			  )
			UNION
			-- locked nodes with no live bounty hunt ...
			UNION
			-- hashing nodes with no active decryption event ...
			UNION
			-- draining nodes whose owning session ended
			SELECT pn.id FROM player_nodes pn
			JOIN botnets bot ON bot.id = pn.botnet_id
			WHERE pn.state = 'draining'
			  AND pn.locked_at IS NOT NULL
			  AND NOT EXISTS (
			    SELECT 1 FROM siphon_sessions ss
			    WHERE ss.id = pn.siphon_session_id AND ss.status = 'active'
			  )
		)
		UPDATE player_nodes
		SET state = CASE WHEN health < 70 THEN 'degraded' ELSE 'healthy' END,
		    locked_at = NULL
		WHERE id IN (SELECT id FROM orphaned)
	`)
	// ...
}

There *used to be* a fifth arm here — a war_committed reaper that found nodes whose war op had resolved. Deleting it is trivial. The hard part is being confident the remaining four arms don’t have a hidden war dependency. CodeRabbit read the query and was satisfied that they didn’t. A human reviewer would have to do the same read; CodeRabbit did it in the time it took me to refill my coffee.

The SQL-in-Go the AI actually flagged

CodeRabbit did have an opinion about this file — a Major on the draining arm of that reaper. The bot noticed that when the reaper resets an orphaned draining node, it clears state and locked_at but leaves siphon_session_id dangling:

UPDATE player_nodes
SET state = CASE WHEN health < 70 THEN 'degraded' ELSE 'healthy' END,
    locked_at = NULL
WHERE id IN (SELECT id FROM orphaned)

Its suggested fix:

 UPDATE player_nodes
 SET state = CASE WHEN health < 70 THEN 'degraded' ELSE 'healthy' END,
    locked_at = NULL,
    siphon_session_id = NULL
WHERE id IN (SELECT id FROM orphaned)

This is a *real* observation about state hygiene in a reaper query. I ultimately didn’t take it — and here’s the honest part of an honest review.

The feature that sold me: “Prompt for AI Agents”

Every CodeRabbit comment ships with a collapsible **🤖 Prompt for AI Agents** — a machine-readable instruction formatted for a coding agent. The real one for the reaper finding:

Verify each finding against current code. Fix only still-valid issues, skip the

rest with a brief reason, keep changes minimal, and validate.

In `@backend/internal/db/botnets.go` around lines 2783 - 2796, Update the reaper’s

player_nodes UPDATE for orphaned draining nodes to clear siphon_session_id along

with resetting state and locked_at. Ensure reused nodes no longer retain stale

siphon ownership that could be acted on by delayed UnlockNodesBySiphonSession

cleanup.

This is the workflow shift. You don’t read the comment and paste it into your agent — you hand it the prompt and it knows the file, the line range, the intent, and the validation contract. I ran my whole review-fix loop this way: collect the prompts → feed them to my coding agent → have it assess each against the current Go and fix only the still-valid ones. The review stops being a thing you *read* and becomes a thing you *execute*.

The three review profiles

CodeRabbit offers three, set in .coderabbit.yaml:

Quiet: Only the most important findings, inline | Mature codebases, noisy PRs, low reviewer bandwidth |

Chill: *(what I used)* | Balanced — Majors and Minors, nitpicks separated | General purpose; the sane default |

Assertive: More feedback, may feel like nitpicking | Greenfield, junior-heavy teams, strict bars |

I ran Chill and it felt right for a removal PR. Assertive on 218 files would have fatigued me; Quiet would be my pick for a hotfix where I only want “will this break prod?”

So, is it worth it?

Here’s the honest accounting for Go shops specifically. Go gives you a strong type system, `go vet`, `staticcheck`, and good test tooling — so a lot of what AI review catches in dynamically-typed languages, Go already catches at compile time. What’s *left* for an AI reviewer in Go is exactly what bit m here: raw SQL embedded as string literals, interface/method consistency across a big refactor, and cross-file invariants the compiler can’ see.

`botnets.go` is 3,500 lines of `pgx` queries against a state machine living in a Postgres `CHECK` constraint — no Go tool in my toolchain reasons about the SQL inside those backticks. CodeRabbit does.

The mental model that worked for me: CodeRabbit is a very fast, very thorough junior reviewer who never gets tired but never says “I don’t know, what do you think?” It always has an opinion, and some will be wrong in the particular way a competent-but-context-light reviewer’s are. Your job shifts from *finding* issues to *adjudicating* them — strictly faster work.

On a 74,000-line removal PR, it caught two real things I’d missed and cost me maybe ten minutes adjudicating the few misses. For a Go team too small for thorough human review — it’s worth a serious look.

Review your next PR with CodeRabbit Review Today

One reason is that we don’t use Go at my current company. We mostly use TypeScript, about which I still have mixed feelings, but to be fair, it works pretty well for us nevertheless. So I won’t blame TypeScript much here.

I still maintain a few Go projects, so I write at least some amount of Go from time to time.

But oh boy, I miss writing more of it.

Especially I miss the developer experience. Nothing even comes close for me, and interestingly, I think that becomes even more important in the AI era. And in this article I’d like to rant a bit about that.

Sponsor

AI writes more code than ever. Reviewing it shouldn’t mean scrolling forty files in alphabetical order.

CodeRabbit Review reorganizes any pull request from a flat file list into a structured, layer-by-layer walkthrough - the logical reading order of the change, not the order your platform happens to sort it. Every range gets its own plain-language summary, with sequence diagrams, state machines, and ERDs generated inline wherever a visual earns its place.

Cohorts group related files and chunks so you review one idea at a time. Layers order them so foundational changes - data shapes, contracts - come before the code that depends on them. Code Peek lets you click any variable, function, class or type to see its definition and usages without leaving the tab, while Semantic Diff view cuts past formatting noise to show what actually changed.

Open it straight from the Review Change Stack button in the PR Walkthrough. Navigate cohorts and layers from the keyboard, comment against exact line ranges and submit native reviews, comments and approvals post back to GitHub or GitLab right where your team expects them.

In the early access, available for free to everyone.

From the team that pioneered AI code reviews. 2M reviews every week. 6M repos. 15K customers.The review interface built for the way modern PRs are actually written.

Review your next PR with CodeRabbit Review Today

Things are clearly changing now with coding agents, and the way we write code. I don’t mean all of us, by the way, I still have huge respect for people who manually craft software without relying heavily on AI. I think there will always be space for that level of engineering craftsmanship.

So, things are changing, for better or worse, I am still not completely sure, but you can already see some trends forming. Rust and TypeScript are becoming dominant choices in AI-generated code, while some other languages… let’s just say you hear less and less about them.

So the real question is: what programming languages will still matter in 5 years from now?

I think we will see fewer dynamic Backend languages in new projects. Ruby on Rails, PHP, maybe even Python for some Backend workloads. Not because those languages are bad, obviously. Many of them are fantastic for humans.

You see, without AI, languages competed a lot on human ergonomics. Now they also compete on machine ergonomics.

Take Ruby on Rails for example. It is incredibly human-friendly, but I would argue not necessarily machine-friendly, performance-wise and typing-wise. Humans can navigate conventions, implicit magic, and DSLs very naturally because they understand context. Models struggle more with that. Explicit systems are simply easier for them to reason about.

And then there are new so-called AI-native languages.

• Zero

  • Honestly, reading that I am still not sure what are the strengths here

• Vera

  • they even route the docs differently for humans or agents. Is it different?

And honestly, I still don’t fully understand the pitch. Both of them feel like AI generated slop languages made with a prompt like “Hey, make me a programming language, do not make mistakes”.

Models today are trained mostly on existing languages and existing ecosystems. So how exactly are they suddenly supposed to generate perfect code in a completely new language with no mature tooling, no massive production codebase, no battle testing, and very little real-world data?

What about security, compilation? Feels like a blackbox.

So right now, ecosystems still matter a lot.

And that is where Go becomes really interesting.

Because in my opinion, and many people will disagree, Go is actually an extremely good language for LLMs. Not just for humans, but for models too. And honestly, I am really rooting for it to win this competition.

So let’s review a few things that I think make Go uniquely good for the agentic era.

First, the standard library is absolutely massive and incredibly well-designed. You can build real production systems with surprisingly few dependencies. HTTP servers, JSON handling, crypto, testing, concurrency, file systems — most of it is already there.

And another important thing: the Go team takes security and stability very seriously. You rarely hear about catastrophic ecosystem-level security disasters coming from the Go standard library itself.

Then there is the compiler. Go compiles insanely fast.

That matters much more in the AI era than people realize. Humans can tolerate slower feedback loops. Agents really cannot. AI systems might compile and iterate hundreds of times while solving a task. Fast compilation directly improves that workflow.

Then you have:

• single static binary distribution

• built-in formatting

• powerful cross-compilation

• minimal dependency hell

• simple and intentionally boring syntax

• Go is pragmatic. It has one mostly obvious way to do things

  • And this is actually one of Go’s greatest strengths. Go intentionally removed many ways to write “creative” code. There are simply fewer ways to make a mess, which means AI-generated Go code often ends up looking surprisingly clean and maintainable.

One of my favorite features: Go’s compatibility promise.

Back in Go 1, the team introduced a compatibility guarantee that basically says old programs should continue working on newer Go versions.

This sounds boring until you compare it to some modern JavaScript ecosystems where dependencies from two years ago already stop working.

I can still open Go projects I wrote almost 10 years ago and run them on a modern Go version without issues.

That level of stability is honestly extremely rare.

And I think stability might become one of the most valuable engineering properties again, especially when AI starts generating massive amounts of code. The last thing anyone wants is millions of lines of generated code depending on fragile ecosystems that break every six months.

Let’s actually try it.

I found one of my old projects (10 years old): https://github.com/plutov/games

It just runs.

I also think formatting matters much more than people admit, especially while humans still review AI-generated code.

And gofmt alone adds enormous value here.

Every Go project looks roughly the same. The style guide is basically built into the language itself. You do not spend time debating formatting rules or installing fifteen prettier plugins and linter configs.

You just run: gofmt

And when AI generates code, this consistency becomes even more valuable because stylistic entropy never really accumulates.

Then comes go vet, linting, which are also consistent between projects.

Another massively underrated feature is cross-compilation.

This still feels magical to me:

GOOS=windows GOARCH=amd64 go build
GOOS=linux GOARCH=arm64 go build

And that’s it.

You instantly get binaries for completely different platforms without setting up complicated build pipelines or external tooling.

Again, fewer moving parts.

Fewer things that break.

That matters a lot when autonomous agents start building and deploying systems end-to-end.

And again, error handling.

Some people dislike Go’s error handling because it is verbose, but others love it because it is explicit.

err := os.ReadFile()
if err != nil {
    // ...
}

And honestly, for AI-generated code, explicitness is amazing.

The control flow is obvious. The failure paths are visible. There is much less hidden magic and much less ambiguity. Models generally perform better when the code is straightforward and deterministic.

You are almost forced to think about failure cases.

And that is a good thing.

And then there is concurrency.

Go still has one of the nicest concurrency models ever designed.

go fetchData()

Even today, spawning concurrent work in Go feels absurdly lightweight compared to many other ecosystems.

Simple primitives. Simple mental model.

One slightly controversial opinion I have is that AI might actually make boring languages more valuable, not less.

Because maintainability scales better than cleverness.

Generated code does not need to be genius-level engineering. It needs to be understandable, stable, refactorable, and easy to verify.

And Go is proudly boring in exactly the right ways.

I don’t know whether Go will become the dominant AI-era language.

Maybe it won’t.

But I do think it will age incredibly well.

Go still feels refreshingly simple.

And honestly, simplicity might end up being one of the most important features in the entire AI era.

Links

• Go compatibility promise

• CodeRabbit Review

• Discuss on Hacker News

Cline is an open-source AI coding agent focused on real software work. Most developers first encounter Cline as an assistant in the editor or terminal, but Cline is broader than a single interface.

It has both a CLI and an SDK:

• The CLI is for running agent workflows directly from the terminal

• The SDK is for embedding the same agent runtime inside your own scripts, products, CI jobs, and internal tools

That distinction matters. In the Cline SDK launch post, the team explains that the original product started inside the VS Code extension, and over time the runtime became harder to separate from the IDE around it. The SDK is the answer to that problem: the agent runtime is treated as a shared service rather than an implementation detail hidden inside one app.

That is also why the SDK is more interesting than a thin API wrapper, the same runtime now powers Cline across the CLI and IDE surfaces, while staying open for other teams to embed in their own products. The low-level agent loop stays reusable, and the stateful runtime around it becomes more durable, portable, and product-agnostic.

Read more

Most databases persist data to disk, but the underlying files are usually opaque: binary blobs, internal formats, encrypted pages. You cannot just open a file, edit a few lines, and expect the database state to change.

But using the filesystem itself as the source of truth can be surprisingly powerful.

For my personal blog, I use Hugo. Articles are just Markdown files in a Git repository. In a way, that already behaves like a tiny database: posts have authors, tags, metadata, version history, collaboration via Git.

$ tree

├── about.md
├── an-ode-to-logging.md
├── benchmark-grpc-protobuf-vs-http-json.md
├── books-2025.md
├── building-slack-bot-with-go.md
├── centrally-collecting-events-in-go-microservices.md
├── concurrency-data-race.md

It is simple and ergonomic.

But once the number of files grows, searching, indexing, querying, and connecting data becomes painful. Filesystems are not databases.

So the obvious question is:

Read more

In a single-player game, state is easy. There’s one player, one save file, and as long as you don’t corrupt the file, you’re fine.

In a live multiplayer game, state is the hardest problem you’ll have. Two players can act on the same target at the same time. A scheduled job (a build, a launder, a raid) needs to resolve at exactly the right moment regardless of who’s online. A player can come back after three days and expect their progress to be where they left it, plus whatever happened in the world while they were gone.

You can’t naively keep this in memory. You can’t lazily flush to disk on logout. You need a real persistence story, and you need it to handle concurrent access without melting.

Here’s the architecture I landed on.

Read more

Introduction

Every game has a core loop. In a shooter it's: see → aim → shoot → reload. In an idle game it’s: click → earn → upgrade. The loop is the heartbeat of the design: the smaller it is and the better it feels, the more the rest of the game can hang off it.

For a browser-based multiplayer game, the core loop is harder than it looks. Browsers are not a great real-time runtime. Players come and go. Tabs sleep. WebSocket disconnect on Wi-Fi handovers. You cannot rely on every player being online at the same time, and you definitely cannot rely on a 60Hz tick.

So you have two choices: pretend the browser is a real-time engine and fight it, or accept that your loop is fundamentally async and design around that.

I went with the second option. Here is what I learned.

Read more

It’s also remarkably extensible. You can write plugins in TypeScript, apply custom themes, build tools and web apps around it, and even extend it with Skills. The community around it is growing fast — check out awesome-opencode or opencode.cafe if you want to explore what people are building.

What I recently discovered, though, is that Opencode has a Go SDK (not to be confused with Opencode Go), and that’s what inspired this whole project. Let’s see what we can build with it.

The Problem: Catching dumb mistakes before commit

I’m the type of developer who absolutely hates typos in code and stray debug print statements — and also the type who produces them constantly. Regular formatters and linters don’t always catch these things, and let’s be honest: other code reviewers aren’t exactly trustworthy either. Nobody really reads the code anymore.

There are tools like CodeRabbit, GitHub Copilot, and Graphite that can review your pull requests after the fact. But what if I want to run similar checks before committing my code? And what if I want those checks to be configurable?

The idea: run an AI-powered code review as a pre-commit hook, using a coding agent that’s already aware of the codebase.

Since I use Opencode daily, let’s build it with that.

Read more

I was hoping that I could try the latest version 3, but it’s not yet released. But that shouldn’t be a problem as v2 is more than enough to create a lightweight desktop app.

Short recap of how Wails works, I won’t Go into the details, you can check it yourself:

A Wails application is a standard Go application, with a webkit frontend. It is possible to bind Go methods to the frontend, and these will appear as JavaScript methods that can be called, just as if they were local JavaScript methods.

Read more

Intro

Building services that sit on top of a Postgres replication slot and continuously stream data into Elasticsearch is a great way to get low‑latency search without hammering your primary database with ad‑hoc queries. But as soon as traffic ramps up, these services become a stress test for Go’s memory allocator, garbage collector, and JSON stack.

This post walks through optimizations applied to a real-world service that:

• Connects to a Postgres replication slot

• Transforms and enriches the change events

• Uses Elasticsearch’s bulk indexer to index and delete documents

The constraints: the service cannot stop reading from the replication slot for long (or Postgres disk will grow), and it cannot buffer unbounded data in memory (or Go’s heap will). The goal is to keep latency and memory stable under sustained high volume.

Read more

• It isn’t the most character efficient or human-readable.

• UUID v1/v2 is impractical in many environments, as it requires access to a unique, stable MAC address.

• UUID v3/v5 requires a unique seed.

• UUID v4 provides no other information than true randomness, which can lead to database fragmentation in data structures like B-trees, ultimately hurting write performance.

Introducing the ULID Identifier

Few projects I worked on used the ULID (Universally Unique Lexicographically Sortable Identifier), and I really enjoyed working with it, and would love to share this experience with you. Specifically for Go programs using Postgres database. But the same applies to other languages or databases too.

You can find the full spec here - github.com/ulid/spec

ulid() // 01ARZ3NDEKTSV4RRFFQ69G5FAV

Read more

However, I wanted to do something in Go, so I started with Conway’s Game of Life. There are various options from C bindings to OpenGL and SDL2 to full game engines such as Ebitengine. I went with raylib-go as it was a good mixture of low-level and abstracted programming.

In this tutorial, we’ll use Go and raylib-go to create Conway’s Game of Life, a simulation where simple rules create endless patterns. By the end, you’ll have gliders drifting, pulsars pulsing, and even a glider gun firing across your screen.

The Game of Life

Conway’s Game of Life is a cellular automaton created by John Conway. It is a zero-player game which evolves. Each generation is built on the previous generation using a set of simple rules.

The game requires no players as you start it off, and it starts to evolve without intervention. It is Turing Complete and can simulate a wide variety of different patterns and Turing Machines.

It starts with an initial game start, then it uses the following rules to determine which cell lives or dies:

1. Any live cell with fewer than 2 live neighbours dies, as if by underpopulation.

2. Any live cell with 2 or 3 live neighbours lives on to the next generation.

3. Any live cell with more than 3 live neighbours dies, as if by overpopulation.

4. Any dead cell with exactly 3 live neighbours becomes a live cell, as if by reproduction.

Each generation or frame in the context of our game will use these rules to determine the next state.

Demo

In this tutorial, we will be creating a simple cellular automation in Go using raylib-go. It will start with a state we define, and allow us to modify the state to see different evolutions.

Read more

I was at a ContainerDays conference recently and attended a great talk from Nikolay Kuznetsov about the Outbox pattern and resilient system design. It seemed like a powerful solution to a common problem in distributed systems, so I decided to dive deeper, and I want to share what I've learned and summarize for our readers in this post.

The challenge in event-driven systems

In modern, event-driven architectures, services often communicate asynchronously using a message broker. A typical flow looks like this: a service receives a request, updates its own database, and then publishes an event to notify other services about the change. Or these two actions happen in parallel.

Here's the problem: what happens if the database commit succeeds, but the subsequent call to the message broker fails? Maybe the broker is temporarily down, or there's a network glitch. Or what if the database is not available at that time? Or what if the program somehow crashes?

You end up in an inconsistent state. Your local database has the new data, but the rest of the system never gets the notification. This is a serious issue because the database operation and the message publishing are not atomic - they don't succeed or fail as a single, indivisible unit.

Read more

I don’t know about you, but I love code reviews.

The power of code reviews

There are different ways to conduct a code review (mailing lists, pull/merge requests, even the code printouts), but they all serve the same main purposes.

• 🐛 Help catch bugs early, which can save time and resources later in the development cycle.

• ✅ Help maintain high code quality and adhere to the code standards, performance considerations, etc.

• 💬 Code reviews can improve team communication. They create a platform for discussing design decisions and coding standards. This dialogue can lead to better solutions and a more cohesive team.

• 📚 Promote knowledge sharing among team members. When developers review each other's code, they learn different approaches and techniques, which can enhance their skills.

Read more

What are Redis Streams ?

A Redis stream acts as an append-only log where each new entry is assigned a unique, time-based ID. Unlike traditional logs, Redis Streams support random access in O(1) time and enable complex consumption patterns, such as consumer groups for distributed processing. This makes them suitable for scenarios where you need to record, syndicate, and process events in real time.

Key characteristics:

• Append-only: Once data is written, it cannot be modified.

• Immutable entries: Each entry is a set of key-value pairs with a unique ID.

• Real-time syndication: Multiple consumers can process events as they arrive.

• Trimming and retention: Streams can be trimmed to prevent unbounded growth.

Read more

For example, there is a circumflex TUI that lets you read Hacker News from your Terminal.

clx

Read more

In modern CI/CD pipelines, supporting multiple architectures for Docker image builds, specifically amd64 and arm64, is crucial. This ensures compatibility for your team, whether they're on Apple silicon or Intel machines, and aligns with your production infrastructure.

If you don’t have access to Github Runners or Machines in your CI/CD with both architectures, you might be using emulation, like QEMU and it can be quite slow to build an arm64 image on an amd64 machine.

That’s why you can optimize your builds and use cache to make it faster.

This article details a robust 3-step workflow for achieving efficient multiplatform builds and covers best practices for frontend (FE) projects where static assets should be built only once for amd64.

Read more

In this article we will dive into the standard itself to make sure we understand how JWT works. We will also implement a secure Go server that can issue JWTs and verify them. And finally we will review some best practices for securely using JWTs.

Use Cases

The most common use case for JWT is authorization. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Usually sent in a header, for example “Authorization”.

Read more

Introduction

Change Data Capture (CDC) enables real-time tracking of database changes, critical for event-driven systems, analytics pipelines, and synchronizing microservices. This guide walks through implementing PostgreSQL CDC in Go using native logical replication and the pgx driver.

1. Understanding PostgreSQL CDC

PostgreSQL provides CDC via logical replication, which decodes changes from the write-ahead log (WAL) into consumable events (inserts/updates/deletes). Key concepts:

• Replication Slots: Persistent channels for streaming changes.

• Publications: Define which tables to monitor.

• Logical Decoding Plugins: Convert WAL entries to readable formats (e.g., pgoutput, wal2json).

2. Prerequisites

a) PostgreSQL configured for replication

# postgresql.conf  
wal_level = logical  
max_replication_slots = 5

In GCP with cloudSQL, you have to enable some flags:

cloudsql.logical_decoding = on 

b) Replication user

CREATE ROLE repl_user WITH LOGIN REPLICATION PASSWORD 'password';  
GRANT SELECT ON ALL TABLES IN SCHEMA public TO repl_user;

Read more