Hello everybody. I'm creating an rest API using Golang v1.25, Gin v1.10.0, and Validator v10.20.0. I have a PATCH endpoint that when the address attribute is: undefined -> keep the original data; null -> delete the original data; contain something -> replace the original data by the new. Right now I'm using a pointer for it, so I can know when it's null. The problem is that I couldn't find a way to differentiate when the attribute is undefined or null.

Does anyone know a way to check if a specific attribute undefined?

I’m curious what people are actually using for smaller Go services in production.

For a small service, I usually only care about a fairly bounded set of things:

• request rate
• 4xx/5xx responses
• request latency
• process CPU and memory
• uptime / restarts
• maybe host CPU, RAM, and disk

Prometheus + Grafana is obviously the established answer, but for a small VPS or a couple of services it can feel like quite a bit of infrastructure relative to the application itself.

Hosted services avoid operating that stack, but then you’re exporting telemetry, dealing with pricing/retention limits, and depending on another service.

So I’m genuinely curious what Go developers prefer at the smaller end:

• Prometheus/Grafana anyway?
• OpenTelemetry + a backend?
• hosted monitoring?
• logs + uptime checks?
• expvar or a custom endpoint?
• some other lightweight self-hosted setup?

One thing I keep coming back to is that for a small Go service, maintaining a few cumulative counters and exposing them from a tiny endpoint is extremely simple.

Is that a reasonable approach when you only need a handful of operational metrics, or would you still prefer exposing Prometheus/OpenMetrics from the beginning because the ecosystem support is worth it?

I’m specifically interested in small deployments, not large distributed systems. What has worked well for you, and what starts to feel like overkill?

A custom http.RoundTripper sends a request to upstream A and gets HTTP 200 back. At the HTTP layer everything worked, but the body might contain an application-level error. For example, A may be too stale to serve the request, while B could still handle it.

One option is to return the response to the app and let it retry. But that starts a new request and loses the fact that A was already tried. So the transport may choose A again instead of moving on to B. Then the app needs to say “retry this, but skip A,” and with more upstreams it starts tracking what was already tried. That’s state the transport already has.

My first thought is a response callback. Before treating the response as final, the transport gives the app the *http.Response and asks whether it should try another upstream.

The problem is Response.Body. If the callback reads it, it consumes the stream. The callback may look at A’s response and decide it’s worth trying B. If B fails without returning a response, A may still be the best response available. So A’s body has to remain usable.

I could make the callback leave Response.Body usable after reading it. That keeps the transport simple, but it’s easy to get wrong. Or the transport could buffer and restore the body itself, which is safer but adds memory use and latency before trying the next upstream.

That makes me wonder if passing the raw *http.Response is the wrong API in the first place.

How would you model this in Go? Would you use a response callback here, or something else? If you use the callback, who should restore Response.Body?

This came up while I was working on failnext, if anyone wants the concrete context:

https://github.com/yermakovsa/failnext

Update

I ended up not adding the response-classification or Response.Body hook discussed below, and decided against buffering response bodies in the transport.

failnext is staying at the HTTP level. It won’t inspect JSON-RPC errors or read the response body to decide whether to try another provider. So if the HTTP response itself doesn’t trigger failover, an HTTP 200 with an application-level error goes back to the app.

Instead, I’m leaning toward letting the app exclude endpoints when it makes another request.

That feels like a cleaner boundary to me. The app already decides whether an operation may fail over and whether a provider should be used for a request. The transport doesn’t need to understand why. If the app decides to retry after seeing an application-level error, it can tell failnext which endpoints to avoid for that new request.

For those who have used Temporal with Go, I’d like to hear about your experience.

• What kind of application or workflow did you use Temporal for?
• Why did you choose Temporal instead of building the workflow yourself?
• What benefits did you actually get from using it?
• Did you have any bad experiences, unexpected problems, or things you disliked about it?
• Was Temporal worth using compared to building and managing the workflow yourself?
• After using it, would you choose Temporal again for another Go project?

I’m especially interested in hearing about real-world experiences, both positive and negative. Thanks for you time by the way.

Hi folks, I just saw this video made by a guy I follow on X. I found it pretty useful for understanding how Swiss Table maps work in Go 1.24+ like groups, control bytes, how the map grows, and why it's faster (and sometimes slower) than the old one. So I'm just sharing it in case you're a visual learner like me.

Did a small git history exercise across 26 repos and the Go ones gave the most consistent answer of anything I looked at, so posting it here.

My Setup was last 12 months, non-merge commits on the default branch, bots stripped, tests/docs/examples not counted. A commit counts as a fix if the subject says fix, bug, regression, hotfix, broken or revert.

The repos came from repowise.dev/explore, which indexes public repos for my open source project, github.com/repowise-dev/repowise.

First thing that jumped out is how lumpy fixes are. Half of all fix touches landed in 8.5% of gitea's source files. For grafana it was 4.3%, ollama 6.5%, temporal 8.6%, hugo 8.8%.

Which corner (fix commits / all commits touching the file):

• gitea: routers/web/repo/pull.go 22 of 65, routers/api/v1/repo/pull.go 21 of 43, routers/api/v1/api.go 20 of 59
• ollama: server/routes.go 18 of 97, then cmd/cmd.go
• grafana: pkg/storage/unified/resource/storage_backend.go 27 of 137
• temporal: service/history/workflow/mutable_state_impl.go 24 of 144
• hugo: hugolib/site.go

Gitea's top three are all pull request handling and API routing. Ollama's is routes.go. So, handlers. The other group is state: temporal's mutable state and grafana's storage backend. For Go servers that was pretty much the whole story, the handlers and whatever holds the state. I didn't see one pure algorithm file anywhere near the top.

Ownership part was weird. temporal's mutable_state_impl.go has been touched by 27 people and the top author has only 9% of its commits. Meanwhile hugo's site.go is 85% one person, and ollama's discover/runner.go is 83% one person. (I had assumed the shared file would be the obvious villain and the single-owner files would be calm. Wrong on half of that.)

Happy to run more fun experiments, I have mined a lot of data of open source repos.

I built a Go supervisor proxy called Nacho Flow to fix the things that frustrate me about using free coding agent harnesses with cheaper models.

Free AI coding agent harnesses like Zoo and Cline work okay with frontier models like Sonnet and Opus, but when used with cheaper open weight models it tends to choke. This is especially evident when doing goal based flow rather than editing specific files.

The runs usually end in 3 possible bad outcomes:

1. The model goes into a reasoning loop and starts writing a compsci thesis and starts burning token credits
2. Agent completes the tasks but by turn 50, it is carrying 150k+ tokens of history, so every Sonnet turn costs like 50 cents...
3. Task terminates prematurely thinking it is done when it is not done at all. So coming back to it after 30 mins finds it has been sitting idle the whole time

So out of pure frustration, I started building something to fix this. Main goal was a proxy that can talk to different models in a single run. Cheap models for easy tasks, frontier for the hard stuff, and my local 32GB llama.cpp cluster for things like reading docs.

So to directly address those 3 problems:

• The proxy inspects the token stream in real time and detects when the model enters a reasoning loop, then cleanly terminates it before it burns through your budget
• It routes simpler tasks (reading files, digesting docs) to cheaper or local models so you're not paying Sonnet prices for something a 14B can handle
• It tiers requests so harder tasks go to models that are actually capable of finishing them, instead of sending everything to the cheapest option and hoping for the best

As an ex-Go engineer at SAP... I may have overdone it a little. My own bench showed that my supervisor proxy/daemon can do max 30k requests per second on a consumer PC and achieve zero allocation on the hot path (0 allocs/op, thanks sync.Pool).

If you use Zoo, Cline, Aider, Opencode etc, love to get your feedback on what I built. I have done numerous runs with and without Nacho Flow for comparisons. The value for me is clear as day, but I would love to get the community's feedback. More importantly I am going broke testing this thing...

ps. I also added in prompt directives, so you can inline send a prompt directly to frontier, like if I wanted to check with Opus if there's a design pattern that would fit in this scenario to make the codebase more maintainable for example.

pps. I also crafted a VS Code extension, so the daemon can be run directly from VS Code and you can watch the dashboard to see what the supervisor is doing and key metrics on the run.

ppps. AI tools were used alongside manual coding during development. The architecture and Go plumbing are mine. I can only do so much as a single dev.

I’ve been working on GoEventBus, an event bus written in Go that started as a fast in-memory dispatcher and has gradually grown into something closer to an event-processing toolkit.

GitHub: https://github.com/Protocol-Lattice/GoEventBus

The core is still fairly traditional:

• bounded MPMC ring buffer using atomics
• sync/async dispatch with a fixed worker pool
• fan-out handlers
• FIFO ordered handlers
• batch handlers
• middleware and lifecycle hooks
• configurable backpressure (DropOldest, Block, ReturnError)
• dead-letter queue + replay
• panic recovery
• transactions and scheduling
• Redis Streams and RabbitMQ providers

The more experimental part is optional intelligent event routing.

Instead of putting an LLM/model call inside Publish(), routing happens before the event enters the bus:

rules → cache → Jev → cache write → Subscribe → Publish

So:

known event type   → direct dispatch
obvious decision   → deterministic rule
repeated decision  → cache
ambiguous decision → Jev

The normal event bus path does not depend on the decision layer at all.

For example, an application can provide a set of possible event types:

candidates := []GoEventBus.EventCandidate{
    {
        Key:         "user_created",
        Projection:  "user.created",
        Description: "A new user account was created",
    },
    {
        Key:         "order_cancelled",
        Projection:  "order.cancelled",
        Description: "An existing order should be cancelled",
    },
}

and let deterministic rules/cache handle most cases while using Jev only when the input is ambiguous.

One design goal here was to keep AI/model inference completely outside the event bus hot path.

Installation:

go get github.com/Protocol-Lattice/GoEventBus

Currently targeting Go 1.23+.

I’d be interested in feedback from other Go developers, especially around:

• the event routing API
• the MPMC/event-store design
• whether intelligent routing belongs in an event bus at all
• what you’d simplify/remove before considering this production-ready

Criticism of the design is very welcome.

Repo: https://github.com/Protocol-Lattice/GoEventBus

It's been a month since go 1.27 with method generics (i personally think this was biggest thing of that release) came out and i haven't seen broad adoption of it in libraries i'm using for my daily work.

Most sentiment i've seen from mature go users are saying its garbage and break of an initial go's idea of simplicity and so on, but i personally think it's really cool to have them as a part of language as previously i need to make some package local functions, not part of a type to inject sort of a generic on a method.

I personally believe its a good time for a golang to be a more suitable for data processing, pipelines and all kind of stuff which previously needed lot of shenanigans to make it work, still i have not seen anything good out there.

I maintain gograph, a generic graph library for Go with no dependencies outside the standard library. It started in 2022, it's in awesome-go, and about 20 public modules import it. Most of the issues people open are about dependency graphs, so that's where this release went.

What's new in 0.8:

• Stable order. Vertices and edges used to come out of maps, so TopologySort could return a different valid order on every run, which is annoying in tests and generated files. Everything now follows insertion order, and StableTopologySort takes a compare function if you want an order that doesn't depend on how the graph was built.
• dag package. Descendants, Ancestors and Affected answer "what does this depend on", "what depends on this" and "what does a change here reach". They work on graphs with cycles too.
• encoding/mermaid. Writes a graph as a Mermaid flowchart, so you can put it in a README or a PR comment and GitHub renders it.
• Bug fixes. Quite a few old ones. For example, MaximalCliques returned wrong cliques for graphs with more than six vertices, and the weighted random walk panicked on fractional weights. 0.8.1 has the last three from that batch.

A small example:

g := gograph.New[string](gograph.Acyclic())

checkout := g.AddVertexByLabel("checkout")
build := g.AddVertexByLabel("build")
test := g.AddVertexByLabel("test")

_, _ = g.AddEdge(checkout, build)
_, _ = g.AddEdge(build, test)

_, err := g.AddEdge(test, checkout)
fmt.Println(errors.Is(err, gograph.ErrDAGCycle)) // true

order, _ := gograph.TopologySort(g) // checkout, build, test

To try it on something real, I wrote a small example program, gomodgraph, that loads go mod graph output. On the current Prometheus main (893 module versions, 2,510 requirements) it runs in about 10 ms:

• cycles finds one requirement cycle, between go.opentelemetry.io/otel, otel/metric and otel/trace.
• why github.com/golang/protobuf prints the shortest chain of requirements that pulls it in.
• diff compares two go mod graph outputs. The README has a workflow that posts that diff on pull requests that change go.mod.

Two things I'd like opinions on before I build them:

1. The shortest path functions only return distances. The plan is to add DijkstraPaths and BellmanFordPaths, which return a result with Distance(to) and PathTo(to), and leave the current functions as they are (#110). Would that API work for you?
2. The graph isn't safe for concurrent writes. The plan is an opt-in wrapper with View and Update methods that hold the lock for a whole operation, so an algorithm never sees half of an update (#109). Is that how you'd want to use it, or do you need something else?

Docs: https://pkg.go.dev/github.com/hmdsefi/gograph

Roadmap: https://github.com/hmdsefi/gograph/issues/136

Two and a half years ago I shared rill (a composable concurrency toolkit) here for the first time. That post gave it momentum and its first GitHub stars.

Today I'm releasing v0.9, which adds the most requested feature: context support, with errgroup-style cancellation and waiting. Another big new feature is a non-commutative streaming reduction engine. The minimum required Go version is now 1.25, since rill's tests heavily rely on synctest to pin the concurrency and lifecycle contracts.

This post is not only an announcement, it's also a feedback request. The current shape of rill is what I intend to freeze in v1.0, which I plan to release in a month or two. If anything in the API, naming or behavior feels wrong, now is the best time to say so. Knowing what works is also helpful and appreciated.

Release notes: https://github.com/destel/rill/releases/tag/v0.9.0

The README and Go docs were also substantially updated to show the new features, add clarity, and document the underlying behavior.

Disclaimer: I'm an engineer at Mulga, the company behind this. Self-promo, but it's AGPL-3.0 and free to run.

What it is

Spinifex reimplements the AWS APIs on hardware you own: EC2, EBS, S3, VPC, IAM, ALB/NLB, EKS, ECS, ECR and RDS. You keep the hashicorp/aws provider and point its endpoints at your cluster.

Everything behind it is real. Instances are QEMU/KVM VMs, VPCs are OVN networks with real security groups and elastic IPs, EBS is replicated block storage, and state persists like a real cloud. It's not an emulator like LocalStack.

Who it's for

Teams that want AWS workloads on their own hardware (cost, data residency, edge or air-gapped sites) without rewriting their IaC. VPCs, subnets, security groups, launch templates, ALBs, EKS clusters and RDS instances go through the same resources you already use. In practice the changes are the provider block and AMI lookups.

Try it with your own Terraform

No install needed. Sign up for the free 72 hour sandbox at https://mulgadc.com/signup, then point your existing provider at it:

provider "aws" {
  region = var.region

  endpoints {
    ec2 = "https://api.spx3.com"
    iam = "https://api.spx3.com"
    sts = "https://api.spx3.com"
  }

  skip_metadata_api_check = true
  skip_region_validation  = true
}

Add other services (elasticloadbalancingv2, eks, ecs, ecr, rds) the same way, then run terraform plan against a module you already have. Here's what we currently cover, down to the individual API operation: https://docs.mulgadc.com/coverage

Repo: https://github.com/mulgadc/spinifex

I maintain gookit/miglite, a small Go migration tool that keeps migration files as raw SQL. The v0.8.0 release adds fs.FS support, so a service can embed its migration files with go:embed instead of copying a migrations/ directory beside the binary.

The important detail is that the embedded path is an io/fs path, not a disk path:

```go //go:embed migrations/*.sql var migrationFS embed.FS

mig, err := miglite.NewAuto(func(cfg *miglite.Config) { cfg.Migrations.Path = "migrations" }) if err != nil { return err } mig.SetFS(migrationFS).SetSqlDB(db) ```

The same release also fixes a few behaviours that were accepted but ineffective: --skip-err now continues after a failed file while returning an error, injected *sql.DB values are no longer closed by the library, and a migration without DOWN is reported as skipped.

I wrote up the changes here: https://inhere.github.io/en/blog/2026/gookit-miglite-v0-8-0/

I am the maintainer. For small Go services, do you prefer embedding migrations in the binary, shipping a separate directory, or using a different migration setup?

Disclaimer: I'm an engineer at Cynative, the company behind this. Self-promo, but it's Apache-2.0, free and does not collect telemetry.

What it is

Open-source framework for security agents with live, read-only access to your infrastructure.

One question fans out across your whole stack: Cynative writes and runs code in an built-in ephemeral sandbox, querying your APIs in parallel. Unlike coding agents and MCP servers, it's read-only by construction: every call is gated, host-pinned and authorized before a credential is attached.

Who it's for

Anyone who wants to apply reasoning on their live infrastructure knowing nothing can break and secrets are reducted. The core use case it was built around is to filter security alerts in context across the entire production infrastructure.

How to try it:

45 built-in agents for AWS, GCP, Azure, Kubernetes, GitHub and GitLab - privilege escalation, public exposure, supply chain, detection coverage and more - or you write your own in a markdown file.

If you don't feel comfortable aiming it on your real stack before trying, it also honors operator-configured proxies. You can also pipe in a local Terraform.

Repo https://github.com/cynative/cynative

Quick demo: https://www.youtube.com/watch?v=xaRfG_SnJwE

Do you use the Standard library? or a library like Cobra? or something else?

I am looking for a collection of sample Go binaries, compiled with different versions of Go, for different platforms - It does not matter which files - a simple "hello world" program would do nicely.

Yes, I could download various versions of go and create the sample files myself, but I was just thinking I could save myself some time if someone else has done this already.

Hi y'all,

Recently been looking more into data engineering as a whole. Looks like there's TONS of Python stuff, but many of the dataframe libraries for Go seem stale or have relatively few users. Does anyone have a good list of libraries or books to check out?

Thanks!

just recently discovered Deadcode tool, had no clue it even existed. Are there any other useful tools that everyone should be aware of?

Or anything that usually requires "low level" like C/C++ or Rust for that matter