Podcast episode with Jon Bodner (author of Learning Go). We talked about Go’s design, lessons from C & Java, and how AI may change the way we write software.

[https://youtu.be/eZKZLx-rJ-I?si=QUyZzsBPJj5Ibw4P](https://youtu.be/eZKZLx-rJ-I?si=QUyZzsBPJj5Ibw4P))

Going through some Go code with the help of a static analyzer (by one of the developers of the analyzer)

Hey everyone, been working on this project for a while and just pushed v4.

It's called ZenTorrent , basically a torrent streaming client that also does direct cloud playback when torrents have no seeders. The whole thing compiles into a single binary, around 38MB, no CGo.

The problem I kept running into was that most torrent clients either need a full desktop GUI or they just download files. I wanted something where I could type a movie name in my terminal and it just starts playing. So that's what this does , it searches across multiple sources, picks the best stream, and pipes it to mpv/vlc or an embedded web player.

The part I'm most happy with technically is the multi-tier fallback. It tries debrid caches first (Real-Debrid, TorBox) using errgroup with a hard timeout, then falls back to regular P2P via anacrolix/torrent, and if the swarm is dead (which happens a lot since ISPs block UDP), it automatically switches to HLS cloud sources. All of this happens without the user doing anything.

The TUI is built with bubbletea and lipgloss. There's also a local web dashboard embedded into the binary with go:embed , it's a single 5k line HTML file that serves on localhost:8888 with search, metadata, episode navigation, and a video player. I added watch parties recently too where you can sync playback with friends through a room code, which was a fun rabbit hole with mutex-guarded state sync.

The metadata catalog uses modernc.org/sqlite (pure Go) and syncs TMDB daily exports in a background goroutine on launch. WebRTC peer connections go through pion/webrtc for browser-based torrent peers.

About 20k lines of Go across 80 files. Been my main side project and I learned a ton about concurrency patterns, especially around managing multiple goroutines with different timeout budgets racing against each other.

Would love feedback on the code structure or architecture , this is the biggest Go project I've worked on and I'm sure there's stuff I'm doing wrong.

https://github.com/subwaycookiecrunch/zentorrent

I built a small Windows utility in pure Go (no cgo, cross-compiled from Linux): a global hotkey that cycles Discord's per-app output volume via WASAPI (go-wca), with a raw Win32 GUI (no framework) and a system tray icon.

It works — but it intermittently hangs after anywhere from seconds to ~30 minutes. Windows logs "Application Hang" (Event 1002) and kills it. No Go panic, no crash dump.

The weird part: it hangs during pure idle as often as during active use, and even a watchdog goroutine that dumps all goroutine stacks at ~4 seconds of stall produces nothing — which points at either a whole-process freeze or an external kill, not a single blocked syscall.

I've stopped guessing and written up the full evidence trail — timeline, what I tried, what I ruled out (leak theory disproven with handle counts, low-level keyboard hook removed, COM apartment re-init fixed), and the open hypotheses (loader lock, COM STA re-entrancy, blocked file write).

Repo (source + a ready-to-run .exe + the DEBUGGING.md writeup):

https://github.com/maxbotlabs/discord-volume-toggle

If anyone's hit a similar "hangs with no stack dump" wall in Go on Windows, or spots something in the code I'm missing, I'd genuinely appreciate the fresh eyes.

Hey everyone,

I'm working on an AI agent-based startup and recently I've been thinking a lot about the backend architecture.

Right now I'm considering something like:

React → Go backend → Python AI service → LangGraph → PostgreSQL

Basically, Go would handle the normal backend stuff like users, auth, projects, APIs, database operations, business logic, etc.

Python would only be responsible for the AI side — LangGraph workflows, LLM calls, agents/reasoning, structured outputs and so on.

My main reason for considering Go is scalability and performance. I know Python can scale, but Go seems like a better fit for a core backend in the long run because of concurrency, lower memory usage, strong typing, and generally better performance.

But I'm also wondering if I'm just overengineering this too early.

The simpler option would obviously be:

React → Django/FastAPI → LangGraph → PostgreSQL

and then move performance-sensitive parts to Go later if we actually need it.

My concern with that approach is that if the product grows a lot, migrating the core backend later could become a huge pain. So part of me thinks it might be better to make that decision early.

For people who have actually built AI/agent products in production, what would you do?

Would you start with Go + Python from day one, or keep everything in Python until there's an actual scaling problem?

Also curious if anyone here has built a similar Go + Python architecture. Did having two services/languages become annoying, or was the separation worth it?

I'm not really looking for benchmark comparisons. I'd love to hear actual production experiences.

The Vercel AI SDK (TypeScript) is the cleanest provider-agnostic LLM API I have used, so I ported it to Go:

https://github.com/azrtydxb/go-ai-sdk

• One API across 39 providers (OpenAI, Anthropic, Google, Mistral, Bedrock, Vertex, Cohere, ElevenLabs, DeepSeek, xAI, Groq, ...): generate text, stream, structured objects, tool calls, embeddings, images/speech/transcriptions.
• Native Go, not a TS mirror: context.Context, iter.Seq for streaming, generics for structured output, typed errors (errors.As on 4xx/5xx).
• Zero dependencies in the root module. The OpenTelemetry bridge is a separate opt-in module.
• MCP client (stdio + Streamable HTTP, elicitation, sampling, roots) in-tree.
• Compat-test harness: every provider is tested against the same golden behavior matrix.

Feedback welcome, especially on the streaming design (iter.Seq + context cancellation) and the provider options type system.

I've written some REST API backend in other programming languages such as Python with FastAPI and Java with Spring Boot.

I just learned Go while ago and now I'd like to implement REST API backend written in Golang. I saw there are gazillion of framework but I don't know which ones suits my case.

The backend have to handle users (with authentication, authorization etc), websocket and maybe nice ORM.

I tried asking many LLMs and I'm not getting any reasonable answer as to why nobody does this . I've been learning Go for the past year and decided to build a normal restapi backend with sqlx and jwt auth.

I came across struct embedding for the first time with jwt.RegisterdClaims which caught my attention quite quickly cause I'd previously gone through the dependency injection with constructor functions across two packages which took me some effort to understand.

I wanna ask why we don't just embed the connection pool struct (sqlx.Db) into the other structs we go on to declare so that it's much clearer and we don't have to deal with plenty references and addresses.

I separate functions that query the database (repository functions) from the handler functions for easy testing and reuse of the repository functions. so I had to start with the normal struct with a constructor function for the package repo like this;
`` type Repository struct {

DB *sqlx.DB

}

func NewRepository(db *sqlx.DB) *Repository {

return &Repository{ DB: db }

} ```

and do same for the handlers package like this too...

``` type Pool struct {

Repo *repository.Repository

}

func newPool(repo *repository.Repository) *Pool {

return &Pool{Repo: repo}

} ```

Won't embedding save us all the headache from the struct and pointer spaghetti and the need for a constructor function whenever you want to introduce the connection pool into another package?

Have you had a chance to use these yet? Personally, I haven’t, but I can see myself reaching for them in the future. Similarly to how I think about Generics in 1.18.

This language was supposed to be easy, with simple syntax. It was designed for people to build apps without thinking about DI management like in Spring, or learning a bunch of methods from a library.

But it turned out people weren’t ready for such a solution. They got used to the language’s simplicity, then asked for extra features like iterators and generics, and started building things that look like Kotlin and Java. Now I see code like req.GetSomething.OrDefault(2).

Yes, there were design issues when Go was initially implemented. I wish it had language-level optionals, because I want pointers to be used for references and mutation, not for nullability.

Now I see custom code where people build their own optional wrappers, and recently I saw a proposal to add collection types, which is basically the Java way.

We benchmarked Go 1.27 simd vs LLVM generated Go assembly (AVX and AVX512) on The Intel Core i7-11370H (supports AVX512).

Full article: Go 1.27 SIMD Benchmark: Can It Replace GoAT Generated AVX512?

The new simd package achieves comprable performace but still trails the AVX512 assembly generated by LLVM on long vectors and horizontal reductions (dot and euclidean):

• An FP32 vector of length 16, exactly the number of values held by one 512-bit AVX512 register.

• An FP32 vector of length 32.

• An FP32 vector of length 64.

• An FP32 vector of length 128.

Hey fellow Go devs,

Just wanted to share something I recently did for work. I created an internal tool using the Go BubbleTea TUI framework. Within the tool, we can perform admin tasks, monitor the way data is changing across several services, manage migrations, and more. It's been really powerful for solving customer issues and routine maintenance tasks. Not only that, but it looks gorgeous as well.

The MVC pattern it follows is pretty intuitive and minimal. No need for an entire 3rd party tool or even a web UI. We just auth with AWS via the terminal and the TUI can run in the context of our applications in each environment.

That's the post really. Shoutout to the creators of BubbleTea, I've really enjoyed building this!

When I first shared CloudEmu, the pitch was simple: I was tired of needing a real cloud account (and a bill) or a running Docker daemon just to test code that calls S3, DynamoDB, and friends. So I wrote a pure-Go emulator that speaks the real cloud wire protocols in memory — you point unmodified SDKs or CLIs at it and they just work.

The feedback pushed me to fix the two things that actually mattered. Installing it used to mean cloning and building; now it's a single brew command (or one static, zero-dependency binary — I kept the core CGO-off on purpose, with the heavy real-engine stuff opt-in and separate). And the built-in Kubernetes support went from an object store to something that behaves like a real cluster — you can kubectl against it and get shows real columns, rollout status completes, events show up.

Being honest, since this crowd rightly asks: it emulates the API surface your code calls, not real infrastructure, and LocalStack still has deeper per-service AWS depth. CloudEmu's bet is multi-cloud, a real k8s data-plane, and being small enough to embed straight into Go tests.

Repo's below — genuinely curious what people think of the wire-protocol approach, and PRs/issues welcome: https://github.com/stackshy/cloudemu

I’m building a small Go HTTP service with PostgreSQL. At the moment, main.go creates the config, database pool, router, and the concrete services/repositories, then starts the server.

I like that everything is easy to follow in one place, but I’m wondering where people draw the line before main.go becomes a dumping ground.

Do you usually keep it as the composition root and move only the implementation details elsewhere? Or do you introduce an app struct, a bootstrap package, or another pattern even for a small service?

I’m not looking for a universal architecture just examples of what has stayed pleasant to work with after the project grew a bit.

I recently worked on happycontext, a Go wide-logging library that builds one structured event during a request and writes it when the request finishes.

The public API stayed compatible. The biggest improvement was a filtered zerolog write:

• Before: 237 ns
• After: 3.07 ns
• Result: 77× faster, 0 bytes, 0 allocations

A filtered write is a log call that the logger ignores because its level is below the configured minimum.

What changed

This work shipped in two pull requests:

• PR 18: remove hot-path allocations
• PR 19: remove unnecessary work

The main changes were:

• Use slog.LogAttrs instead of boxing every attribute into any.
• Reuse bounded attribute buffers.
• Avoid repeated configuration validation and map cloning.
• Select one policy instead of scanning every policy.
• Apply sampling before cloning event fields.
• Replace shared atomic sampler state with math/rand/v2.
• Check logger levels before converting fields.
• Remove an unused zerolog event that consumed an extra sampling decision.

Some results:

The sampler became slightly slower in a serial microbenchmark, but more than 30× faster under parallel load. That was the important trade-off for request middleware.

Typical usage

A normal net/http service can keep its existing logger and add request fields through happycontext:

```go logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

mw := stdhc.Middleware(hc.Config{ Sink: slogadapter.New(logger), SamplingRate: 1.0, Message: "request_completed", })

mux := http.NewServeMux() mux.HandleFunc("GET /orders/{id}", func(w http.ResponseWriter, r *http.Request) { hc.Add(r.Context(), "user_id", "u_8472", "feature", "checkout")

if err := processOrder(r.Context()); err != nil {
    hc.Error(r.Context(), err)
    http.Error(w, "internal error", http.StatusInternalServerError)
    return
}

w.WriteHeader(http.StatusOK)

})

_ = http.ListenAndServe(":8080", mw(mux)) ```

The slog adapter can be replaced with the existing zap or zerolog adapters.

How AI was used

I used an AI coding agent to:

• Turn profiling results into a ranked plan.
• Inspect affected callers.
• Implement the two pull requests.
• Add adversarial and compatibility tests.
• Run benchmarks in separate worktrees.
• Review race-detector and allocation results.
• Challenge optimizations that did not matter.

AI did not decide what shipped. Measurements did.

We rejected an HTTP status fast path that saved about 0.33 ns. We also rejected a custom sampling threshold that improved the new path by less than 3%.

The final verification included race tests, go vet, static analysis, heap-retention checks, concurrent API tests, and repeated adapter benchmarks.

Reproduce the benchmarks

```bash cd benches

go test -run '<sup>$'</sup> -bench '<sup>BenchmarkAdapter'</sup> -benchmem -count=5 go test -run '<sup>$'</sup> -bench '<sup>BenchmarkRouter'</sup> -benchmem -count=3 go test -run '<sup>$'</sup> -bench '<sup>Benchmark'</sup> -benchmem ```

Use the same Go version, machine, and multiple benchmark samples when comparing results.

The percentages from the two pull requests should not be added together. They use different baselines and some gains overlap.

The general lesson was simple: the fastest work is often work you can prove is unnecessary.

• Check the log level before converting fields.
• Sample before cloning.
• Select one policy before normalizing everything.
• Reuse configuration only inside a read-only boundary.
• Remove shared contention from the hot path.

Project: github.com/happytoolin/happycontext

Full write-up: How We Used AI to Make happycontext Up to 77× Faster

EDIT - Fixed formatting

Hi Gophers!

Almost 10 years ago I started building gobwas/glob, a glob-pattern matching library for Go, which many of you have adopted since.

Its core design was technically interesting -- a tree of matchers, with fast paths and heuristic optimisations here and there -- but it had bugs (obviously!), which the community kept kindly pointing out over the years (and I'm very grateful for that!). The trouble with technically interesting designs is that they are often hard to maintain once the context washes out of your head. And that's exactly what happened next -- as it so often goes with open-source side projects -- my focus drifted away from the project for a very long time, though the thought of improving it never quite left the back of my mind. Finally the stars aligned and the right moment came to act on those thoughts and pay off my inner debt to the library -- and, wildly inspired by Russ Cox's glob article, I found the time to rewrite most of the matching engine into something I believe is much simpler, yet performs nearly the same.

The new engine is one small package: a compact backtracking walk over a much-slimmed-down matcher tree. The package shrank by a good ~2000 lines of code. The part I'm happiest about is correctness -- every bug ever reported is now covered by unit tests, and on top of that there is fuzzing that compares glob against a drop-in regexp equivalent: if a random glob pattern matches a string, its regexp translation must match it too. The fuzzer caught real bugs during the rewrite already!

I decided to tag it v1.0.0 straight away -- same import path, and for the typical MustCompile(pattern).Match(s) use it's a drop-in upgrade; the one visible change is that the glob.Glob interface got replaced by the concrete *glob.Pattern type with the same API shape.

Feedback and bug reports are welcome!

Best,

Sergey.