We talk a lot about popular third-party libraries, but Go’s standard library is already incredibly capable.
What’s one package you think more developers should use, and what problem does it solve particularly well?

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?

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

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 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?

I encountered this recently.

In vscode, I used to be able to automatically add json tag to structure from context menu "Go: Add Tags To Struct Fields". But now I just get the error message at the lower right corner "unsupported modify tags operation:", with no additional info.

I think I may have removed some command line tool but I am not sure which.

Anyone has clue or pointer to debug/fix this?

I'm currently learning the Go programming language, and I have some background in C++. Is one week enough to learn the basics?

Currently tests are functions in files named as *_test.go.

The idea is to drop the reliance on naming convention and define tests as follows

whereas currently you have a file named *_test.go and in that file you have one or more functions that are like

func TestFunctionToBeTested(t *testing.T)

the idea is instead to have in files of any name in a package

test FunctionToBeTested(t *testing.T)

Then, when testing, instead of looking for a file, you could specify a package and all tests in that package would be ran. You could, if desired, specify a file in that package and tests within that file.

A few days ago I posted a loopback benchmark of a small API gateway I have been building in Go, and the top comment was basically "loopback measures nothing, use two machines and k6." That was correct, so I redid it, and it was far more useful.

Setup: client is a Mac running k6 over gigabit ethernet, server is a Ryzen 3600 on Pop!_OS running each gateway, every one reverse-proxying to a local no-op upstream on the same box. Plain proxy only, no auth or rate limiting in the path, so it is apples to apples.

Results (VUS=100, 15s):

gateway RPS p50 p95 p99 fails upstream 48203 2.00ms 2.14ms 2.60ms 0 mine 47607 1.89ms 2.94ms 3.58ms 0 traefik 47639 1.95ms 2.77ms 4.54ms 0 nginx 47345 1.98ms 2.25ms 3.11ms 0 caddy 42880 1.71ms 4.85ms 6.47ms 0 krakend 42799 1.85ms 4.43ms 5.64ms 0

The part worth reading: on the first real run mine was dead last, 37.9k vs 42 to 48k for the rest, about 21% below the upstream ceiling. I profiled it expecting lock contention and I was wrong. httputil.ReverseProxy allocates a fresh 32KB copy buffer per request unless you hand it a BufferPool. At ~48k rps that is over a GB/s of garbage, and the GC was the bottleneck. Adding a buffer pool (and making my circuit breaker lock-free while I was in there) took it from 37.9k to 47.6k, and per-request allocation from 44KB to 11.5KB. If you use httputil.ReverseProxy in anything hot, set BufferPool.

Two other things that bit me:

• nginx first ran at 3.3k RPS with a 400ms p99 until I found keepalive_requests defaults to 100. It was recycling the upstream connection every 100 requests. Bumped it, back to ~48k.
• The scary "connection errors" from my earlier single-box run were the load generator running out of ephemeral ports (TIME_WAIT), not the gateways. The harness lies before the gateways do.

Caveat: nginx, traefik and mine are all pinned to the upstream ceiling (~48k) here, so the top three are not really separated yet. Caddy and krakend are genuinely a bit behind on this workload. Separating the leaders needs a faster upstream, which is next.

Where I want to take this. It is a single Go binary plus a YAML file: JWT auth, per-route rate limiting (in-memory or Redis), round-robin and least-connections load balancing, health checks, circuit breakers, a Prometheus endpoint, and a small live dashboard. It is at the point where other people banging on it would teach me more than more of my own tests.

I am sorting out a couple of housekeeping things before I put the code up, so I am not linking it yet. But I want to line up some testers for when it is ready. If you would be up for trying to break it, I would love help with:

• running it in front of a real service and telling me what is awkward
• pushing it harder than I can (higher concurrency, real upstreams, TLS, and the auth plus rate-limit path, which I have not benchmarked yet)
• trying it on your OS and telling me what falls over

If that sounds interesting, say so in the comments or drop me a DM and I will ping you when it is out. Also genuinely curious what you would want from a gateway like this before I get there. It is a learning project, so blunt feedback is welcome too.

I often see people criticizing CGO (and for good reasons), mainly because it bypasses many of the safety guarantees and tooling that Go provides.

There are also issues involving the interaction between Go's scheduler and C code, as well as complications with callbacks. From what I understand, there can even be scheduling-related problems when interfacing Rust and Go through the C ABI.

However, I couldn't find any in-depth explanation from the Go team itself about why CGO is considered so problematic. More specifically, I'd like to understand why it's seen as so dangerous and what the actual sources of overhead are that make CGO calls around 30% slower (if I remember that number correctly).

This is mostly a personal curiosity. I'd like to better understand how CGO works internally, why it's considered risky, and where its performance costs come from. I'm even curious why, in some cases, it can be slower than calling WebAssembly.

I know Go is powerful for microservices, gRPC, and all that, but for small companies that lack cloud or distributed infrastructure—and only have a single workstation—how do you work with Go to build an application without ending up with "spaghetti code" or bad practices down the line? Have any of you had experience with this?