Go Analysis Framework: modular static analysis by go team

hoppp

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

jamescun

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

b7e7d855b448

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

ksec

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

jzelinskie

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

verdverm

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

mchav

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

bijowo1676

the most valuable thing in this article for me was this: The early loop looked like this: /goal improve the perf by 20% -> a great deal of plausible code -> a confusing benchmark -> another plausible patch Later it looked like this: find the expensive work -> explain why it happens -> change one mechanism -> compare with the previous Rust revision -> test the complete application -> retain, revise, or reject

eonwe

This is one of the least informative discussions in HN front page that I remember.