Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Can these sorts of primitives be used to create broader "architectural" linters?by mchav
- Yes, and I use them often in the context of writing adversarial ‘go vet’ style anti-slop analyzers that run pre-commit.by fractorial
- I was just looking for this. Will give it a spin.by hoppp
- So what is context? This isn't new and why the submission ?by ksec
- Someone in the thread about the Ruff update ingenuously said they wished Go had something like Ruff, being unaware of this framework. In that thread, someone seemed to take it as a sign that many people who might care to know about this don't yet, so they made a dedicated post for it.by hxtk
- the most valuable thing in this article for me was this:
The early loop looked like this:
Later it looked like this:/goal improve the perf by 20% -> a great deal of plausible code -> a confusing benchmark -> another plausible patchfind the expensive work -> explain why it happens -> change one mechanism -> compare with the previous Rust revision -> test the complete application -> retain, revise, or rejectby bijowo1676 - This is one of the least informative discussions in HN front page that I remember.by eonwe
- 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...
by verdverm - 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...
by jamescun - I visited that link three years ago. It isn't new. It's nifty, though.by tgv
- It was mentioned in the Ruff article comments and probably reposted.by stephbook
- 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
by jzelinskie - 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.)
by b7e7d855b448 - I think that the best feature that go was able to create is a very strong community around the language, where practices are as important as the language itself. Maybe these practices are what makes the community strong?by vander_elst
- I do love the batteries included attitude. Having benchmarking included as well as a mechanism to run tests to check (test) for race-conditions right from the language/build tool is amazing.
My only wish is that go could become less verbose. There are several frontends to go that are more compact, compile down into golang, and then let you enjoy all the benefits.
by spockz - When I moved from Kotlin to Go because of a job change. it was painful. Apart from its runtime benefits, it is overrated IMO. it lacks basic conveniences. Go is not a simple language, it is a primitive language.by aaa_aaa
- If generics were going to ruin the language, they would have by now. I think you can rest easy.by jerf
- I love how during prototyping, the compiler will tell me off for having an unused variable and fail to compile. I totally love the idea of crashing when writing on a closed channel.by eptcyka
- 100% with you on every point. It's the only language I've worked in that lets me read other codebases without an hour or two of "wut?" happening, so they did something right!by BobbyJo
- > I love the error handling
Even if you prefer manually checking for errors after every call that might fail, I fail to see how one can love go’s verbosity. Compare go’s
with something like (hypothetical)foo, err := bar() if err != nil { return ERR; }
where the compiler, seeing that bar returns an Either<int,err> can enforce the presence of the ||| clause or, alternatively, require later code to check for errors if the ||| clause isn’t present. I think that’s both more robust (prevents one from forgetting to check for errors) and shorter (allowing for showing a lot more code on a screen or page)foo := bar() ||| return ERR;by Someone - Oh yeah totally agree. I don't understand why someone would want to write `slices.Contains(s, needle)` when you can write this beautiful poem like a Shakespeare in VSCode:
Oh and I totally want to build a stack trace manually. It's like doing cardio to me.found := false for _, v := range s { if v == needle { found = true break } }
This is very elegant by the way, so that we need errors.Is now, which has to dynamically check if the error implements Unwrap() error or Unwrap() []error. Because having any language facilities for error handling is harmful.if err != nil { return fmt.Errorf("my function name but in spaces: %w", err); }by wannabe44