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

31–40 of 100 posts

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

#31

Post by irq-1 »

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…

You're right. Just for information, slices.Contains() uses the index, not a copied value.

https://cs.opensource.google/go/go/+/refs/tags/go1.26.5:src/...

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

#32

Post by BobbyJo »

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

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!

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

#34

Post by bayindirh »

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…

> Because having any language facilities for error handling is harmful.

No, making error handling verbose mandatory is meant to make developers do mental cardio and be mindful of what they are doing.

You can either keep developers mindful or punish them after they make a mistake by shouting at them and make them waste their time during re-compiling.

P.S.: Yes, I love Go's error handling mechanics, which makes handling errors mandatory, not optional, and if you ignore the error, this is a deliberate choice and the burden is on the developer. Go does the former, Rust does the latter.

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

#35

Post by sapiogram »

bayindirh wrote: post #34
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…

> Because having any language facilities for error handling is harmful. No, making error handling verbose mandatory is meant to make developers do mental cardio and be mindful of what they are doing. You can either keep developers mindful or punish them after they make a mistake by shouting at them and make them waste their time during re-compiling. P.S.: Yes, I love Go's error handling mechanics, which makes handlin…

What are you talking about, only Rust actually forces you to handle errors. Go functions merely return a tuple with an error along with the result, with a convention that you must checktror a non-nil error before using the result.

Rust bakes this into the type system, a function can truly return a result or an error.

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

#36

Post by bayindirh »

sapiogram wrote: post #35
bayindirh wrote: post #34

Earlier quoted context omitted.

> Because having any language facilities for error handling is harmful. No, making error handling verbose mandatory is meant to make developers do mental cardio and be mindful of what they are doing. You can either keep developers mindful or punish them after they make a mistake by shouting at them and make them waste their time during re-compiling. P.S.: Yes, I love Go's error handling mechanics, which makes handlin…

What are you talking about, only Rust actually forces you to handle errors. Go functions merely return a tuple with an error along with the result, with a convention that you must checktror a non-nil error before using the result. Rust bakes this into the type system, a function can truly return a result or an error.

> with a convention that you must checktror a non-nil error before using the result.

So, you handle the error in the end, or forcefully and intentionally ignore it. Again, if the code goes boom, it's on the developer, not on Go.

> Rust bakes this into the type system, a function can truly return a result or an error.

Error being a variable or baked into the type system doesn't change the practical result. You must handle the error or purposefully ignore it.

> only Rust actually forces you to handle errors.

When you have two programming languages which makes you handle the error, the word only becomes a little invalid.

Semantics doesn't change the result. You have to acknowledge and act on the error either way.

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

#37

Post by TheDong »

b7e7d855b448 wrote: post #21
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…

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

i.e. the blub paradox: https://wiki.c2.com/?BlubParadox

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

#38

Post by resonious »

bayindirh wrote: post #36
sapiogram wrote: post #35

Earlier quoted context omitted.

What are you talking about, only Rust actually forces you to handle errors. Go functions merely return a tuple with an error along with the result, with a convention that you must checktror a non-nil error before using the result. Rust bakes this into the type system, a function can truly return a result or an error.

> with a convention that you must checktror a non-nil error before using the result. So, you handle the error in the end, or forcefully and intentionally ignore it. Again, if the code goes boom, it's on the developer, not on Go. > Rust bakes this into the type system, a function can truly return a result or an error. Error being a variable or baked into the type system doesn't change the practical result. You must ha…

> if the code goes boom, it's on the developer

This is the same argument C (and Zig!) people have for manual memory management. You can avoid memory problems by being a good developer.

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

#39

Post by inigyou »

TheDong wrote: post #37
b7e7d855b448 wrote: post #21

Earlier quoted context omitted.

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

i.e. the blub paradox: https://wiki.c2.com/?BlubParadox

Steelman: the extra complexity of languages more powerful than Blub has not been found to be a good tradeoff. Blub is KISS and that's good.
Post reply on HN