u/sigmoia

If you haven't tried the new "go fix" yet, give it a spin.

It's a proper revival of the old "gofix" idea. In Go 1.26, it was rebuilt on top of the Go analysis framework. So now it can modernize your code with newer language and stdlib features.

It respects the Go version in your module. If your "go.mod" says "go 1.26", it suggests Go 1.26-compatible changes. It doesn't rewrite your code into something your module hasn't opted into.

For teams using LLMs, this is great. You don't need to keep leaving PR comments like “use the newer API here” or “we don't write that pattern anymore.” Run it locally or on the CI instead.

Start from a clean git state:

go fix -diff ./...

Then apply it:

go fix ./...

Then run it again.

Some fixes expose more fixes. The Go team recommends rerunning it, and in practice two passes often catches more than one.

Some useful analyzers:

• forvar
• newexpr
• mapsloop
• minmax
• ... and many more

You can also run one analyzer at a time if you want smaller PRs:

go fix -newexpr ./...
go fix -forvar ./...

That's useful when one pass touches a lot of files and you don't want one giant mixed cleanup patch.

The other neat bit is //go:fix inline. Library authors can use it to help users migrate from old APIs to new APIs. That's much better than deprecating something and hoping everyone reads the changelog.

You can also write your custom analyzer to enforce your own rules. I am writing a few for fun.

The Go blog has two good posts on it:

• Using go fix to modernize Go code
• //go:fix inline and the source-level inliner

I ran it on a large RPC service, and "newexpr" cleaned up a pile of pointer helper calls. Extremely satisfying.

Rust has the Rust book which gives you a great overview of all of Rust. Brown University recently made it interactive and it's quite fun to go through that.

But Go doesn't have anything like that. I get that Go is a much smaller language and doesn't need a full-fledged book, but the Tour of Go doesn't cover much of the tooling. Go is thin in terms of language constructs but quite fat in terms of tooling - pprof, embedding, code gen, runtime tracing, analyzers, and so on.

Is there a book or resource that covers this arena? I have been working with Go since 2017 but my current workplace is just picking it up.

So coworkers going through Effective Go, Code Review Comments, Google Style Guide, Learning Go, and the Tour of Go often mention that unlike the Rust book there's not much in Go that covers the strength of Go, which lies in tooling.

Any good pointers? Thanks!

Pretty much every Go conference in the last two years has had at least one talk on how to build agents from scratch, and then another one on which framework to use.

I am curious about two things:

• Most current agent frameworks don't feel Go-native. Go seems like an afterthought, and the APIs are pretty bad. Google ADK felt a bit better. Many vendors don't even have a first-class Go SDK, which is a shame, since Go is much better suited than TS/Python for this kind of work. Which framework do you use, and how has the experience been with Go?

• What are you even using agents for? To me, agents are slightly smarter REST APIs that can do some extra stuff compared to a deterministic service. Weather apps, travel companions, or smart code formatters are nice. But I am having a hard time figuring out why everyone and their mom is writing one, and what problem you are solving with it.

If you are using Go at scale and doing performance tracking, what does your continuous profiling stack look like?

• Raw pprof with manual scraping?
• Datadog?
• Pyroscope?
• Something else?

I would love to hear about your environment and workflow.

I am also curious which profiles you keep turned on by default. Modern Go tooling has become a lot better, and keeping CPU, heap, and the flight recorder on continuously has minimal performance impact now.

Also, besides eyeballing the data, how do you analyze it? Do you have performance regression tests? Not talking about micro bench marks that run alongside unit tests - rather than tests that catch broad sprectrum perf regressions. What do they look like?

Mostly asking because I am trying to get a sense of the different ways people typically do this. No commercial purpose behind this. Maybe I will write a short blog post about the common workflows at best.

TLDR; Opting for a flatter structure typically guides you organically away from pkg and overly nested internal.

pkg is now used considerably less than it used to be. But it's still fairly common. Mostly because lots of folks coming to Go encounter the standard package layout repo and copy the structure.

pkg is an old vestige from the GOPATH era. Then other large projects like k8s went w/ the structure & never changed it because of the size of the projects and their backward compat promises.

But that doesn't mean we should copy that w/o asking why. The extra layer of nesting makes imports ugly and code discovery harder. pkg pretty much has no place in today's greenfield projects. But I also don't go around rooting it out of existing projects.

Another common one is abusing the /internal directory in svcs. I review a ton of candidate assignment submissions at work, and it's pretty common to see the entire app code shoved into the internal directory. The common rationale is abstraction.

But if it's application code, then no one is importing it. So shoving everything into the internal package is lazy design instead of properly structuring the core subpackages.

In libraries, internal makes sense to keep implementation details away from users of the API. Even there, creating three layers of nesting is a code smell.

Code organization is subjective & contexual. Giving general advice is extremely hard. But one thing I have found teachable is this:

• Go already doesn't allow import cycles
• On top of that, you should design your packages so that dependencies flow inwards. This means outer/adaptor packages can depend on core packages, but core packages should not depend on the outer ones.

myapp/
  order/
    order.go              // package order: Order, LineItem, Status
    repository.go         // package order: Repository interface

  postgres/
    order_repository.go   // package postgres, imports "myapp/order"

  http/
    order_handler.go      // package http, imports "myapp/order"

Here, postgres and http can import order, but order doesn't import either of them. The core package doesn't know / care whether it is being used by HTTP, Postgres, Kafka, or anything else.

This is the only generalized rule that goes a long way for most applications and libraries. Otherwise, eschewing unnecessary nesting and gauging the smell from import paths is the way to go.

Another thing I've found quite helpful is running go doc continuously while developing something. This way, I can assess whether the public API looks ugly and overwhelming from a user's perspective.

At work, I've been doing some agent automation, like pulling in a Slack digest every morning / checking my calendar & posting a summary before I start the day.

I mostly use claude code, and it already has an in-process ticker for scheduling tasks. The issue is that you need to keep the cc process alive or schedule an actual cron job.

Also, for one-shot jobs, you could use at. But on macOS, the atd daemon isn't turned on by default.

So I wrote a tiny tool that works the same way on macOS and Linux. It allows you to schedule:

• cron jobs
• one-shot jobs at a certain wall time

It has its own daemon and lifecycle, which makes sure it works the same way on both platforms. To keep the daemon alive, it uses OS-specific launchd or systemd, so the hard work is offloaded to the OS.

I now just ask the clankers to schedule job using this tool. This allows me to keep track of the jobs, completion state, logs, etc. I’ve been running it for two days, and so far it's working well. You might find it useful.

side note: I wanted to make it a tui but then I realized that the world could probably use one less tui. Also, testing tuis are still hard.

https://github.com/rednafi/eon

Just use slog for structured logging in Go. This zerlog/zap APIs are a pain to deal w/. In 99% of cases, the few extra allocations made by slog simply doesn’t matter.

But the cost of wrangling externel API is there forever. Also, at a fairly large scale,(1000+ k8s pods) we have rarely experienced slog to be reason of tail latency spike. So it makes little sense to default to an idiosyncratic library now that slog is here.

It's better to go with the default and only switch if you have measured slog to be the bottleneck (which it rarely is)

W/ LLMs, now I'm seeing clankers pulling in all three libs in the same codebase & making a mess out of it. Add that with other OTEL circus, half of your codebase turns into this unmaintainable plumbing mess.