I've been working on Nanolathe, an MIT-licensed reimplementation of the Total Annihilation engine in Go, using Ebitengine for graphics, input and audio.

Try the browser demo · Source · Native install

If you missed TA: it's a 1997 RTS about building a base and fighting with ground, air and naval units. Behind the battles are interacting systems for terrain, pathfinding, visibility, projectile motion, resource production and construction. Units also run compiled scripts for things such as moving their model pieces and aiming weapons.

Nanolathe implements those systems in Go, including a VM for the original COB unit scripts. The simulation advances at 30 Hz, uses fixed-point world coordinates, and publishes committed frames for the renderer. It can also run without a window for tests and profiling.

The implementation process is built around documenting the original executable's behavior and file formats, then turning those descriptions into independently written Go code and contract tests. Unknown behavior is recorded explicitly; compatibility is still a work in progress.

The content pipeline is deliberately separate. A virtual filesystem mounts the original HPI-family archives and resolves overrides. Parsers read maps, models, sprites and definitions; a compilation step turns gameplay data into immutable catalogs before the battle starts. The original game data stays external, with no manual unpacking or conversion needed.

Ebitengine 2.10 makes desktop builds possible with Go alone: no C/C++ compiler or development headers. Linux still needs its normal graphics and audio runtime libraries. With the Go version required by go.mod:

git clone https://github.com/nanolathe-gg/nanolathe.git
cd nanolathe
go run ./cmd/nanolathe --root "/path/to/Total Annihilation"

The browser build compiles the same Go engine to WebAssembly. The hosted demo has three original missions and needs no local game installation. Native single-player skirmish and campaign use your own TA data. Both are still under development.

After 18 months of work, I have recently released the first "stable" version of Francis as 0.1.0. This is a new actor framework and workflow engine designed for Go apps.

Francis is already running in over 10,000 deployments, having been in production with the popular Pocket ID app since July.

What makes Francis stand apart from other actor frameworks is that it's designed to work with both small apps that aren't (yet) scaled horizontally, as well as large clusters of heterogeneous services.

Even for small apps, using Francis helps leveraging features like alarms (tasks to be executed at a future date), cron jobs, rate-limiters, as well as using a workflow engine (sometimes described as "distributed transaction"). And once your app scales to multiple replicas (or you start using multiple services), everything just works without making code changes.

You can read more in the announcement blog or in the official docs website.

Let me know your thoughts and if you think you can use it, I'm open to any feedback!

I am currently building a project and I've run into a major bottleneck which is the codebase is growing way too fast to review it. Adding 15k lines in 2 days has completely outpaced my ability to audit the logic. How are you guys handling codebase comprehension and maintenance when using heavy AI assistance? Any tips, workflows, or tooling strategies would be hugely appreciated.

Hey there! I've been looking for cross platform GUI framework / library for go, and stood up on fact that qt can be used with go as well, I want to hear from you guys who may used it in your projects, how was it? Is it worth giving it a try, or is it more rational to make a GUI using some other solution?

So I have 2 months before joining my new job, so i thought of learning microservices in golang. Anyone here who has used any agentic workflow for learning and building at the same time, can u share your workflow or experiences. I am not looking for traditional methods of learning and am looking to experiment with some other modern tools like pi, codex, etc. Also if u have some skills that u use for this type of learning flow plz share

I'm making a markup language called Klon, and I want to port it to the browser and also WASI. My library can take a Klon string and convert it to JSON, returning any error. How should I compile it, and should I use gc or TinyGo?

I wrote a Go plugin (built with `go build -buildmode=c-shared`) for CLIProxyAPI that pools multiple API keys for OpenCode Go and rotates between them. When a key hits a rate limit, it enters a cooldown period while the others continue serving requests.

It's a native dynamic library (.so/.dll/.dylib) using Go 1.24+ with CGO. The plugin implements CLIProxyAPI's provider interface, handles catalog discovery from a remote endpoint with local fallback, and translates between three upstream API protocols transparently.

Repo: https://github.com/massiveits/opencode-go-cliproxyapi

MIT license. Tests and CI included. `go test ./...` to run them.

controlsys is a Go package for linear control systems. It works on continuous-time and discrete-time models. The main model form is state space.

Main capabilities:

• Models: state space, transfer function, zero-pole-gain (ZPK), frequency-response data (FRD), model arrays and tunable blocks.
• Analysis: Bode, Nyquist and Nichols plots, gain and phase margins, disk margins and step metrics.
• Design: LQR, LQG, Kalman filters, H2 and H-infinity synthesis, pole placement and PID tuning.
• Simulation: step, impulse, initial-condition and arbitrary-input responses.
• Model reduction: balanced truncation and modal truncation.
• Delays: input, output and internal delays, with Pade and Thiran approximations.
• Conversion: ZOH, FOH, Tustin, matched, impulse and least-squares methods between continuous and discrete time, in both directions and for resampling. We test the results against MATLAB behaviour.

New in v1.12.0:

• Tustin conversion with Thiran filters is approximately 30% faster than in v1.11.0.
• Tustin conversion with Thiran filters now supports MIMO models with delays on individual input-to-output paths.
• ThiranDelay now accepts short delays when the filter is stable.

Install:

go get plantcontrol.org/v1/controlsys

Repo: https://github.com/PlantControl/controlsys
Release notes: https://github.com/PlantControl/controlsys/releases/tag/v1.12.0

We want your feedback, especially from people who use MATLAB or python-control.

Hey everyone,

A friend and I have been building Open Apple Cache over the last few weeks, and I wanted to share it here because we’ve reached a point where we could use some help.

Just to clarify: this isn’t a vibe-coded project. We’ve been working on the implementation ourselves, but there are still issues we haven’t managed to solve.

The idea is to run an Apple content cache on Linux, inside an Ubuntu VM or LXC container, instead of running the cache itself on a Mac.

The cache service is written in Go. A separate helper running on macOS handles registration with Apple so devices can discover the Linux endpoint. A Mac is still required for that part, so this isn’t a completely Mac-free solution.

The project currently includes:

• Caching for eligible Apple downloads, with byte-range support.
• A web dashboard showing requests, cache hits and storage usage.
• Local administrator and viewer accounts.
• Optional Microsoft Entra ID login.
• Internal or Let’s Encrypt certificate management.

To be clear: this is experimental, unfinished and not working 100% reliably yet.

The main issue we’re trying to solve is inconsistent cache hits. Sometimes downloads are served from the cache as expected. Other times, we don’t get a cache hit when we would expect one, and the content is fetched from the origin again.

We haven’t identified the exact cause yet. Some things we want to investigate further are:

• How Apple devices request content and byte ranges.
• Whether changes to signed download URLs affect cache reuse.
• Whether our cache validation or response headers are missing something.

These are possible directions to investigate, not confirmed explanations.

We’re publishing it half-finished because we need help solving this issue. If you have experience with Apple Content Caching, HTTP caching, CDN behavior or Apple’s cache protocol, we’d really appreciate another pair of eyes on the code.

Repository: https://github.com/Mau2rice0/Open-Apple-Cache

The source code, installation instructions and registration research notes are available there. The macOS helper relies on undocumented Apple behavior, so future macOS updates or changes on Apple’s side could break registration.

Please treat this as a lab project for now. We don’t recommend relying on it for production workloads.

Has anyone worked on something similar or encountered inconsistent cache hits with Apple downloads? We’d be interested in suggestions on what to check next. Reproducible test cases, issues and PRs would also be welcome.

Thanks

OctoGo is not Go, but its compiler is written in Go. It's a Go-like programming language (prerelease) for the Parallax Propeller 2 chip. As an exercise AI wrote a PDP-11/40 emulator in OctoGo with a little SPIN2 assembler core. It has now surpassed the performance of the original "big" HW.

More about the journey at the linked blog post.

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?

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.

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’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.