You guys can keep complaining about how go is too verbose, but I love everything about go.

I love the error handling, I love the forced formatting, i love all the linting it has including style guides. When you read other source code it's so easy to understand it and make sense of it. Thank you go team

(Ok, maybe I am a bit sceptical with the latest generic additions, but overall it's a great language. I love it.)

This isn't new?

You can see it's used by _a lot_ of linters already:

https://pkg.go.dev/golang.org/x/tools/go/analysis?tab=import...

For SpiceDB[0], we've found a lot of success using this framework to define our own analyzers; it's probably 10x easier now with LLMs. No need for tribal knowledge or more time wasted on code review if you can just turn it into a linter and move on.

[0]: https://github.com/authzed/spicedb/tree/main/tools/analyzers

Can these sorts of primitives be used to create broader "architectural" linters?

So what is context? This isn't new and why the submission ?

I was just looking for this. Will give it a spin.

The Go team's emphasis on tooling in the service of software engineering is a boon to human and agentic development alike. Give yourself and your agents great tools.

An example from one of my recent projects: https://github.com/verdverm/gmd/blob/main/Makefile (give agents simple "tool calls" instead of needing to divine the correct args/flags every time, essentially invocable agents.md content)

One of the interesting things to call out from this is using build tags for testing { unit, coverage, recorded, real api }, with the buffet allowing the agent to iterate faster and more targeted. I tend to run the linting and coverage in a new session, have a report generated, and then another fresh session to start dealing with gaps.

Another super cool testing tool in the Go internal source is `testscript`. Roger Peppe extracted a number of those internal utilities here https://github.com/rogpeppe/go-internal/tree/master/testscri...

[flagged]

[flagged]

[flagged]