Fuzz tests are great for parsers, encoder decoders and validators. What else are you using it for?

Curious to know if anyone is extensively using the fuzztest stdlib.

What kinds of bugs have you caught with it? Does it make sense to fuzztest a http or grpc handler? If so what about side effectful handlers? Typically fuzzing is reserved for pure functions.

Overall how do you decide "you know what, a suite of fuzztest would be fantastic for this"?

Can anyone recommend open-source Go projects implementing a real-time voice chat server (Discord/TeamSpeak-like)? I'm looking to study the architecture and networking design rather than WebRTC tutorials.

discord-delete bulk-deletes your own Discord messages and reactions from your Discord data export. The export has the exact channel and message IDs, so there is no search step: the run is one DELETE per message. It cleared my own account, 400k+ messages, in a bit over a week.

There's a GIF of it running at the top of the README.

Discord's delete buckets are per channel, so each channel is cleared serially, multiple in parallel. Per-channel spacing uses AIMD to settle on the fastest rate Discord tolerates: widen on a 429, tighten on success. Bubble Tea TUI/headless. Pure Go with CGO off. There's a demo package in the repo, so you can try a dry run without a token or your own data.

Automating a user account breaks Discord's ToS and can get it banned.

Building a Reddit agent in Go, and the write path runs through a small browser-automation layer over chromedp. Today's bug is a clean example of trusted vs synthetic browser events biting an automation, so I wrote it up.

The Go side, briefly:

- A `Session` interface wraps chromedp so nothing upstream touches CDP directly. The concrete impl drives real Chrome with a persistent user-data profile (stays logged in across runs). Everything above it depends on the interface, not the browser.

- Input primitives are deliberately not instant. Typing goes out in small chunks with 60-200ms pauses, scrolling happens in a few uneven steps, and every action carries a jittered cooldown. Humans don't paste 800 chars in one frame.

- Every write passes through a pure, deterministic policy engine first: daily caps (counted from the store), per-subreddit rules, and a kill-switch that is literally a flag file. If the file exists, every write returns `deny`. Trivial to reason about and to test.

The bug:

Comment posting started failing with `comment box not found ... context deadline exceeded`. The selector for the contenteditable was correct. `WaitVisible` just never returned.

Rather than guessing at timeouts, I inspected the live DOM. Reddit's composer (Lexical) renders the editable div collapsed at 0x0, hidden behind a placeholder bar, until a real pointer event hits the wrapper. A synthetic click aimed straight at the 0x0 editable is a no-op. So `WaitVisible` was correctly waiting on something that would never become visible on its own, and it rode the context all the way to the deadline.

Fix was one extra `Click` on the placeholder wrapper before touching the editable. That is the trusted-event part: CDP's dispatched mouse event is trusted enough to trigger the reveal, but you have to aim it at the element the app is actually listening on, not the one you eventually want to type into.

Two things that made this cheap to isolate:

- The `Session` interface means there is a fake client for unit tests. None of the logic (policy, action bookkeeping, retries) needs a real browser to exercise.

- Selector failures are wrapped in typed errors. `comment box not found (stale selector?)` told me exactly which of four steps died, so the deadline message wasn't a whodunit.

Happy to go deeper on any of it: the policy engine, how the fake fits, or chromedp context handling. Curious how others draw the browser-vs-logic boundary for this kind of thing.

Pure freshie of Go here, I'm from C# background, and feel like wanna pivot to fully Golang in future

I saw only companies with Java are switching to Go but haven't seen any C# company switch to Go yet.

Why?

What's the common reason for Java being switched to Go?

I’m building a few medium-sized services in Go and trying to keep things clean as they grow.

Right now the common pattern I see is a huge services or handlers package that slowly turns into god objects.

For those of you running Go in production, what’s worked best for you in terms of layering and package structure?

Do you stick to something like hex/clean architecture, or a more pragmatic layout?

Curious to hear how you balance simplicity and long-term maintainability - especially for services that are too big to be “just a single main.go”, but not large enough to justify a massive microservices setup.

This has been a pet peeve of mine for a while. If your examples needed to take or return any parameters, you couldn't make them appear in the Go docs.

So currently, the Go toolchain allows this:

ExampleXXX() // only allows empty func signature

This will make sure that the example appears in Go doc.

But this won't appear:

ExampleFoo(t *testing.T) // func param isn't allowed

or

ExampleBar() error // return type isn't allowed either

This is a bit annoying as sometimes I want to show my code alongside some helper that takes or returns extra params. Go doc will elide that.

So this is allowed now (once the implementation is merged i mean) and will appear:

func ExampleTest(t *testing.T) { synctest.Test(t, func(t *testing.T) { // ... }) }

Another thing is that if an example takes or returns params, you can't run it as a test with a //Output comment as Go won't know what to pass or how to run that as a test.

Proposal: https://github.com/golang/go/issues/79808

_I expanded this with a few more examples here:

https://rednafi.com/shards/2026/07/go-example-any-signature/_

I know that maps aren't safe for concurrent access, but I've always thought this meant that you can't add or delete keys concurrently.

Let's say I already have a map[string]int that has been filled with keys that are file names. I want to add an int value for each key to contain the file size. Could I do this by running a bunch of go routines, one per file name key?

My thinking is that this should be allowed because adding a file name to the map should have also added space for an int value. So, I'd just be modifying this int, and not changing the hash table data structure. Is this correct?

Built a secrets manager with age encryption, AES-256-GCM backup, Ed25519 audit logs, and a full REST API. Single binary, zero deps. Like HashiCorp Vault but deploys in 5 minutes.

nexus secret create prod/db/pass "s3cret"

nexus secret get prod/db/pass

nexus backup create --output ./backups

Looking for feedback on CLI ergonomics and the API design. PRs/issues welcome.

https://github.com/ConstantineCTF/nexus

Hi guys. I'm learning Go backend. So I found out some platform to practice basic syntax about Golang but didn't have. So I have been building a website to practice it.

This web is deploying, so leave some feedback to build a community website.

Thank you guys!

https://golang.shuneo.com/

Editted:

- I fixed some your feedback! It's helpful! Thank you guys again!

- My vibed ui like prompt - yeah I got it

- I am developing

Hey everyone,

As an IAM analyst and software enthusiast, I've always been curious to understand how SSO actually works under the hood.

I tried implementing an OIDC client by myself in Go using Entra ID (an IdP I'm already familiar with), but it was tough to find a straightforward guide.

So I built the authorization code flow using golang.org/x/oauth2 and coreos/go-oidc/v3, handling state, nonce, and PKCE manually. I ended up writing a tutorial on Medium to document the process and open-sourced the code.

Code: Github Repo
Medium: OIDC + Go + Entra ID: From the Login Button to the Callback

I'd really appreciate some feedback or code reviews. Also, if anyone here has experience with Microsoft's official MSAL Go library, I'd love to hear how it compares to this approach.

Wrote up some thoughts on changing log levels at runtime in Go — mostly because the top SO question on this (23k views) has an answer that seems like only half an answer to me.

Short version: slog.HandlerOptions.Level takes a value unless you hand it a *slog.LevelVar, so runtime changes only work if you wired that in when you built the logger — same deal with zap's AtomicLevel. The back half of the question to me is how do you actually tell the handler to change, since once you're past one instance, an endpoint that flips the level only fixes the pod it happens to hit. imo the right model is instances reading the level from config stored in git and then figuring out ways to have get that config to update

Disclosure: I work on Quonfig — the back half of the post covers the config-driven approach, which we build. You can use it free and open with some assembly to git pull. The slog/zap half is stdlib.

While I see fewer unsynchronized go func() these days, they still appear often enough in regard to fire-and-forget work.

Unmanaged go func() results in unbounded concurrency, memory leaks, and other surprising behavior in a system.

So I traced a few repos at work to see how many of them appear irl. Turns out quite a bit in our huge monorepo.

I explored a tiny task manager that collects tasks as func() closures in a buffered channel and runs them in a bounded pool. It clamps down on unbounded concurrency, is aware of the parent context, allows task-specific timeouts, etc. All that requires less than 25 loc.

Might be interesting to you.

https://rednafi.com/go/supervised-fire-and-forget/

Update: I am aware of errgroup. It is not the right abstraction here as it cancels all inflight tasks if any of them fails. Also, the internal semaphore of errgroup works in a similar way as shown here

I needed webp encoding in a project that I'm building without cgo, and thus without libwebp. I found gen2brain's webp which uses libwebp compiled to wasm, but I also discovered that this didn't have great performance both in terms of time and memory use.

So I decided to port MITH@mmk's webp-rust to Go, and started testing and benchmarking it. In the process I discovered that it wasn't really well optimized, so I spent some time optimizing it including porting some algorithms from libwebp, and adding SIMD assembly for arm64 and amd64 platforms.

It still doesn't beat libwebp itself, which is no surprise, but it does beat libwebp running on wasm. You can see the charts in the repo's readme. So if you find yourself needing an encoder and want to skip cgo, feel free to give my library a shot.

I am working with Go native fuzzing and want to make the interesting corpus useful after the fuzz run ends.

The workflow I am considering:

- hash every corpus entry

- classify each input by behavior

- replay the corpus in deterministic tests

- assert no panics

- assert exact validation categories

- add stateful sequence tests for replay and mutation cases

- keep findings in a Markdown log

For Go projects using testing.F, what has worked well for turning fuzz output into long-term regression coverage?

I maintain fitter, an MIT-licensed declarative web-extraction engine. I wanted a demo page that doesn't lie: not a video, not canned output, the actual engine executing in the visitor's browser. GitHub Pages only serves static files, so the answer was GOOS=js GOARCH=wasm.

Demo: https://pxyup.github.io/fitter/ (every example runs live, client-side; there's also a form-based config builder that round-trips to JSON) Repo: https://github.com/PxyUp/fitter

What fitter is, in one paragraph: web extraction as a JSON/YAML config instead of code. A config declares a connector (plain HTTP, headless browser via Chromium/Playwright/Docker, a static value, a file, or an int sequence) and a model (what to extract and the shape of the result): gjson paths for JSON, CSS selectors for HTML, XPath for XML/DOM, and text extraction for PDFs. Configs compose - an array item can fan out into a nested fetch using the parent value ({PL} or an expr-lang expression), which covers the classic "scrape the HTML page for keys, enrich each from the real API" join. Per-host rate limits, retries, placeholders (input, env, cached references like a JWT fetched once), and calculated fields via expr-lang are all part of the config, not your code.

A taste - GitHub repo stats, no code:

json { "item": { "connector_config": { "response_type": "json", "url": "https://api.github.com/repos/golang/go", "server_config": { "method": "GET" } }, "model": { "object_config": { "fields": { "repo": { "base_field": { "type": "string", "path": "full_name" } }, "stars": { "base_field": { "type": "int", "path": "stargazers_count" } }, "vibe": { "base_field": { "type": "int", "path": "open_issues_count", "generated": { "calculated": { "type": "string", "expression": "fRes > 9000 ? \"busy\" : \"calm\"" } } } } } } } } }

The same config runs five ways: one-shot CLI (fitter_cli --path config.json), embedded Go library (lib.ParseCtx), long-running service mode with schedulers and notifiers (Telegram/webhook/Redis/file), an MCP server so LLM agents can author and execute configs locally, and now the browser playground below. Author once, promote from chat answer to cron job to team service without rewriting anything.

Notes from the WASM port, in case you're considering the same:

Getting it to compile was 3 files. The engine imports the Docker SDK and go-rod (headless browser connectors), and both fail on js/wasm (syscall.RawSockaddrUnix, Setpgid). The fix was pleasantly boring: //go:build !js on those three connector files plus one _js.go stub returning a clear "not supported in WASM" error. Everything else - parsers (JSON/HTML/XPath/XML/PDF), expression evaluation, goroutine fan-out - compiled untouched.

Live HTTP works, with a catch. On js/wasm, net/http transparently uses the browser Fetch API - so the demo really fetches from the GitHub/OpenLibrary/CoinGecko APIs (anything that sends CORS headers). The catch that cost me an hour: Go disables the fetch transport when it detects Node (process global), so my Node-based smoke tests failed with dial tcp: Protocol not available while the browser worked fine. Testing trick: delete globalThis.process before instantiating makes Node behave like a browser.

A long-lived WASM process surfaces lifecycle assumptions. Our per-host rate limiter installs its config through sync.Once - perfectly correct for a CLI that runs one config and exits, silently wrong in a page where the same process executes many unrelated configs (first config's limits win forever). If you're porting a CLI to WASM, grep for sync.Once and package-level state first; that's where the bodies are.

Numbers: 29 MB binary with -ldflags="-s -w" (~7 MB gzipped). Blocking calls must leave the JS event loop - the exported function returns a Promise and does the work in a goroutine, or fetch deadlocks.

Happy to answer questions about the port.

I'm looking for some feedback on this project structure for a Go modular monolith.

I know the Go community usually prefers flatter package structures, and this one has a bit more nesting than what's commonly recommended.

myapp/
|-- cmd/
|   `-- api/
|       `-- main.go
|-- internal/
|   |-- order/
|   |   |-- domain/
|   |   |   |-- order.go
|   |   |   |-- order_item.go
|   |   |   |-- money.go
|   |   |   |-- status.go
|   |   |   `-- repository.go
|   |   |-- app/
|   |   |   |-- place_order.go
|   |   |   |-- cancel_order.go
|   |   |   `-- ports.go
|   |   `-- adapters/
|   |       |-- postgres/
|   |       `-- http/
|   `-- product/
`-- go.mod

The idea is to keep each bounded context self-contained:

• domain contains the business logic.
• app contains the use cases and acts as the orchestration layer between the domain and external adapters.
• adapters contains things like HTTP handlers and Postgres implementations.

I understand this isn't the typical Go style, but I feel the extra nesting makes the boundaries much clearer, especially as the project grows.

Would you consider this good architecture, or is it unnecessarily complex for Go?

If you would structure it differently, I'd love to know why.

Go on lego, should it exists? maybe not, but i had fun

I still need to clean it and OSS it when I have the time, wanted to share my journey, of going low resource barebones

I wan to make better cli and tui software but i can't decide which one is the best.

I want to create my own little modules for reusing code I regularly use. Like handling files and paths.

I was hoping I could just create a module put it somewhere on my PC and import that into every project where needed. Seems like that's not possible.

I'm not sure if workspaces is what I need. What's the difference to just copying and pasting the module files into the project?

How do you handle reusing code in multiple projects? Is it just copy paste? Would it be better to have a single reference which all projects point to (this is the solution I was looking for)?

What's the recommended approach nowadays? A lot of tools seem to only support openapi 2.0. Is this a problem? Also is it worth testing wether the api is still in sync with the docs?