Hacker News

AbuAssar

Go Analysis Framework: modular static analysis by go team pkg.go.dev

b7e7d855b4482 hours ago

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

wannabe44an hour ago

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:

    found := false
    for _, v := range s {
        if v == needle {
            found = true
            break
        }
    }

Oh and I totally want to build a stack trace manually. It's like doing cardio to me.

    if err != nil {
       return fmt.Errorf("my function name but in spaces: %w", err);
    }

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.

b7e7d855b44827 minutes ago

I don't say it's perfect, but right in this moment I feel most comfortable with go and I don't mind jumping through a few hoops or writing things multiple times

msiean hour ago

You forgot to put /s after your post.

logicchainsan hour ago

Your handwritten one has a major performance bug:

    found := false
    for _, v := range s {
        if v == needle {
            found = true
            break
        }
    }

Do you see it? It copies the v into a local variable, which could be tremendously wasteful if it's a large struct. You should instead be taking a pointer to s[i] and comparing the value there with `needle`.

If you'd used `slices.Contains(s, needle)`, on the other hand, it could have such a performance bug in it and you'd never know.

Someone16 minutes ago

> 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

   foo, err := bar()
   if err != nil {
     return ERR;
   }

with something like (hypothetical)

  foo := bar() ||| 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)

gempir23 minutes ago

It doesn't have a lot of style guides or linting though. You have to install and configure quite a lot of tooling for that

jerf2 hours ago

If generics were going to ruin the language, they would have by now. I think you can rest easy.

ncrucesan hour ago

The greatest thing about generics is … that they're not used much if at all.

Which is a great way to make sure they're not overused, which in my experience is better than underuse.

jzelinskiean hour ago

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

jamescun5 hours ago

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

tgv5 hours ago

I visited that link three years ago. It isn't new. It's nifty, though.

stephbook4 hours ago

It was mentioned in the Ruff article comments and probably reposted.

verdverm10 minutes ago

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

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

ksec2 hours ago

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

hxtk39 minutes ago

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.

hoppp6 hours ago

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

k9294an hour ago

[flagged]

someworkk3 hours ago

[flagged]

dfasifsaf5 hours ago

[flagged]

zikohh4 hours ago

It's spam look at the users history. They just comment the same thing everywhere

zahlman4 hours ago

This is another instance of a spam attack I first noted over a year ago. New accounts all set up to keep linking to this one particular Stack Overflow question. Ref. https://meta.stackoverflow.com/questions/433930/repeated-wav...

[deleted]5 hours agocollapsed

source