Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Analysis Framework: modular static analysis by go team

pkg.go.dev

Post reply on HN
Print view View original

21–30 of 100 posts

Re: Go Analysis Framework: modular static analysis by go team

#21

Post by b7e7d855b448 »

wannabe44 wrote: post #15
b7e7d855b448 wrote: post #11

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

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 i…

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

Re: Go Analysis Framework: modular static analysis by go team

#22

Post by gempir »

b7e7d855b448 wrote: post #11

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

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

Re: Go Analysis Framework: modular static analysis by go team

#23

Post by Someone »

b7e7d855b448 wrote: post #11

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

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

Re: Go Analysis Framework: modular static analysis by go team

#24

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

Re: Go Analysis Framework: modular static analysis by go team

#25

Post by eptcyka »

b7e7d855b448 wrote: post #11

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

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.

Re: Go Analysis Framework: modular static analysis by go team

#26

Post by mathisfun123 »

logicchains wrote: post #16
wannabe44 wrote: post #15

Earlier quoted context omitted.

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 i…

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 pe…

> on the other hand, it could have such a performance bug in it and you'd never know.

wut...? the debate isn't between closed (incompetent) source and open (competent) source - the debate is between verbose language and expressive language.

Re: Go Analysis Framework: modular static analysis by go team

#27

Post by kajman »

logicchains wrote: post #16
wannabe44 wrote: post #15

Earlier quoted context omitted.

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 i…

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 pe…

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

Perhaps you're much better at programming than I am, but I prefer these semantics in a language because I figure they're much more likely to have been optimized empirically, support vectorization, and be less buggy than another rote loop I'm trying to speed through.

Re: Go Analysis Framework: modular static analysis by go team

#28

Post by boredatoms »

logicchains wrote: post #16
wannabe44 wrote: post #15

Earlier quoted context omitted.

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 i…

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 pe…

or contains() could be written by those who can write performant code, ..once

Re: Go Analysis Framework: modular static analysis by go team

#30

Post by spockz »

b7e7d855b448 wrote: post #11

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

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.

Post reply on HN