r/golang

CPU data cache associativity issues are relatively well known. Instruction cache associativity issues, less so.

While working on go code, I investigated a surprising performance regression that turned out to be caused by L1 instruction cache associativity. In the code I didn’t even change.

The investigation included usage of go toolchain, but the underlying issue is mostly language-agnostic.

I’m a Go engineer and I’ve been looking at how teams structure small data sync / ingestion jobs that run repeatedly over time.

Typical pattern in my case (and in systems I’ve worked with):

- Go scripts pulling data from external APIs (Stripe, HubSpot, internal services, etc.)

- some lightweight transformation

- writing into Postgres / S3 / warehouse tables

- executed via cron, CI pipelines, or simple schedulers

What I keep noticing is that once these jobs need to run repeatedly, the “hard part” becomes consistency over time rather than the actual API calls.

Specifically:

1. Incremental loading / avoiding full re-syncs

- using updated_at timestamps

- storing cursors or “last processed id”

- sometimes full re-fetch + deduplication downstream

2. State tracking

- DB table storing last successful sync point

- local file-based state

- or implicit state derived from queries

3. Failure + resume behavior

- full job reruns on failure

- partial retries per batch

- sometimes manual recovery steps when things break mid-run

What I’m trying to understand is:

- Is this just the normal way Go ingestion jobs are built in production?

- Or do teams usually converge on a shared pattern or internal library for handling incremental sync + state + retries?

- At what point does this become something you standardize vs just keep per-job logic?

Curious how others handle this in real systems especially if you’ve had to scale beyond a handful of these jobs.

I done everything in "Getting Started" section, so I intended to start reading the "Effective Go" page, but I got the note:

"This document was written for Go's release in 2009 and is not actively updated. While it remains a good guide for using the core language, it does not cover significant changes to the language (generics), ecosystem (modules), or libraries added since. See issue 28782 for context. For a complete list of changes, see the release notes."

So for you guys with great experience in the language, still worth to read it or it's too old for nowadays?

Hi everyone,

I wanted to drop in and share a small personal AI agent I've been working on.

I wanted to learn more about AI agents by actually building one. I started with a simple, modular agent in Go using the genai lib, but recently moved to Genkit for multi-backend AI support. (I've only tested it with Gemini so far, but Go has been great for this, the compiled binary is under 20 MB and starts instantly).

It started as a simple HTTP tool I could call via curl, but I eventually added Telegram as my main frontend since it's free and easy. As I experimented, I wanted to support multiple tools and agents, so I added MCP option as server and client. Now, my main agent (for me Gemini Flash, thinking disabled) can spin up specialized sub-agents on the fly based on the task. For example, it can call on Gemini Pro for heavy reasoning, or trigger a custom "travel planner" that fetches live Vienna public transport data and returns it in seconds. I can create any custom agent with any custom skill or MCP without polluting the main agent's context much.

Here is a quick rundown of the other features I added:

• RAG: It loads data from a local folder once and keeps it persistently in a vector DB.
• History handling: It "compacts" conversation history based on a message limit, keeping the important context without blowing up the prompt size.
• Dynamic Context: You can inject live CLI command results into the context instead of just static files (like weather data). To avoid spamming external APIs on every call, I built a cachefor CLI tool that caches these command outputs for a set time.

Everything is Dockerized (docker-compose-skill.yml), pulling configs and API keys from a .env file and a few .d folders.

I built this mostly for myself, but I think the architecture could be useful to anyone experimenting. I am open to any feedback or ideas. (Yeah, the code quality and testing could be improved for sure, but this is just a side project for now.)

Repo: https://github.com/Gerifield/hAIry-botter

Heyyy r/golang I have always felt that Go doesnt have some good matrix packages, so I decided to make one, been working on this for almost 4 months now, was slacking a bit due to college exam but finally I completed it, would love some feedback on this!!
Repo link:- https://github.com/Arceus-7/matrix
Go package page:- https://pkg.go.dev/github.com/Arceus-7/matrix
I hope this will be useful for many people <3

I’m trying to get better with Go slices, and I’m having trouble building the right mental model.

When I learn a new language, I usually implement a deck of cards to practice things like traversal, initialization, and shuffling. Right now I’m implementing Fisher-Yates shuffle.

In C, I would write something like this:

void shuffle(int *array, int n) {
  if (n > 1) {
  srand(time(NULL)); 

  for (int i = n - 1; i > 0; i--) { 
    // Pick a random index from 0 to i 
      int j = rand() % (i + 1);
 
      //Swap array[i] with array[j]
         int temp = array[i];
         array[i] = array[j]; 
         array[j] = temp; 
    }

  }
}

This makes sense to me because I can clearly see the temporary variable and the swap.
Now Go's turn

func (d *Deck) Shuffle() {
for i := len(d.Cards) - 1; i > 0; i-- {
  j := rand.IntN(i + 1)
  d.Cards[i], d.Cards[j] = d.Cards[j], d.Cards[i]
  }
}

The part that confuses me is this line:

d.Cards[i], d.Cards[j] = d.Cards[j], d.Cards[i]

I understand that d.Cards is a slice, and that assigning to d.Cards[i] mutates the underlying array. But I don’t understand how this swap works without a temporary variable?

Is Go evaluating the right-hand side first, then assigning both values to the left-hand side? if so is slices the only place golang evaluates right side expressions first?

Also, for people who came from C/C++/Java/C#, did Go slices feel strange at first? Did the mental model eventually click?

If you're running a Golang service that uses SSE or needs to handle a lot of requests, you may want to look into supporting HTTP/2 over cleartext as long as you are behind some sort of load balancer that supports it. I wrote up a quick post showing how to do it in newer Go versions where it is much easier than before. We use Google Cloud Run, and I've included some config examples for that as well.

This is the weekly thread for Small Projects.

The point of this thread is to have looser posting standards than the main board. As such, projects are pretty much only removed from here by the mods for being completely unrelated to Go. However, Reddit often labels posts full of links as being spam, even when they are perfectly sensible things like links to projects, godocs, and an example. r/golang mods are not the ones removing things from this thread and we will allow them as we see the removals.

Please also avoid posts like "why", "we've got a dozen of those", "that looks like AI slop", etc. This the place to put any project people feel like sharing without worrying about those criteria.

Hi,

I wanted to make a post because I want to know what other community members think about this topic: roasting people honest about AI usage on their AI usage.

I have called out many projects in the past that were pure slop, oldest commit 2h ago, obviously vibed but pretending they built it. I was quite mean as well...

I think that's reasonable, we're calling bs out when we see it. Here is where I think we need to reconsider, I just read an article shared here about a person explaining how they vibed a slack tui in a weekend. They had a whole section about how they vibed it, how much time it took and how they did it. People were pointing out that it was made with AI in the comments, and it's like, yeah, they said it in the post, it's not like it's being hidden.

Why do I think we should talk about this? Because if we keep dunking on people who are up front about their AI usage they will start hiding it, eventually blurring the line. I'd much rather people be honest and then we can all decide if we want to support a project and use it or not.

Anyhow, I think it would be interesting to see the subreddit policy updated. I personally like seeing how people are using AI especially if it's in a tech article format. Maybe we could update the subreddit rules to further ban/limit vibed projects while allowing tech articles about how something was vibed?

Maybe I'm totally wrong and y'all just don't care, but I'd like to hear other peoples thoughts on this as I think it's interesting.

Rant over

A simple application for .md files:
- Only necessary features, restrictions foster creativity
- No need to install anything, all you need is a browser
- Works offline
- Local first, you own all your files
- Free and open source, you can tweak it however you want
- Extremely simple code. One person or an LLM can fit the whole project in head
- Portable, no build systems, just open web/index.html
- Out of the box synchronization
- The server is just one binary (or use iCloud/Dropbox/Google Drive for sync)
- Telegram chatbot for on-the-go access to your files

You can save notes, journal, tasks and basically everything in .md files. The best and "lazy" way to do it is through "chat" flow.

Fun fact.
Server infra before the rewrite to Golang:
docker + php-fpm + php7 + larvel + nginx + redis + cron + worker + certbot

Server after the rewrite to Golang:
server, a 15MB no-dependencies binary that has everything.

That's my favourite part of Golang :D

TLDR; Opting for a flatter structure typically guides you organically away from pkg and overly nested internal.

pkg is now used considerably less than it used to be. But it's still fairly common. Mostly because lots of folks coming to Go encounter the standard package layout repo and copy the structure.

pkg is an old vestige from the GOPATH era. Then other large projects like k8s went w/ the structure & never changed it because of the size of the projects and their backward compat promises.

But that doesn't mean we should copy that w/o asking why. The extra layer of nesting makes imports ugly and code discovery harder. pkg pretty much has no place in today's greenfield projects. But I also don't go around rooting it out of existing projects.

Another common one is abusing the /internal directory in svcs. I review a ton of candidate assignment submissions at work, and it's pretty common to see the entire app code shoved into the internal directory. The common rationale is abstraction.

But if it's application code, then no one is importing it. So shoving everything into the internal package is lazy design instead of properly structuring the core subpackages.

In libraries, internal makes sense to keep implementation details away from users of the API. Even there, creating three layers of nesting is a code smell.

Code organization is subjective & contexual. Giving general advice is extremely hard. But one thing I have found teachable is this:

• Go already doesn't allow import cycles
• On top of that, you should design your packages so that dependencies flow inwards. This means outer/adaptor packages can depend on core packages, but core packages should not depend on the outer ones.

myapp/
  order/
    order.go              // package order: Order, LineItem, Status
    repository.go         // package order: Repository interface

  postgres/
    order_repository.go   // package postgres, imports "myapp/order"

  http/
    order_handler.go      // package http, imports "myapp/order"

Here, postgres and http can import order, but order doesn't import either of them. The core package doesn't know / care whether it is being used by HTTP, Postgres, Kafka, or anything else.

This is the only generalized rule that goes a long way for most applications and libraries. Otherwise, eschewing unnecessary nesting and gauging the smell from import paths is the way to go.

Another thing I've found quite helpful is running go doc continuously while developing something. This way, I can assess whether the public API looks ugly and overwhelming from a user's perspective.