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

41–50 of 100 posts

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

#41

Post by tomhp »

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.

Rust is neither the only nor the first language to contain a result type (https://en.wikipedia.org/wiki/Result_type). Definitely a much nicer way to handle errors though.

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

#42

Post by madeofpalk »

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…

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

Except Go doesn’t actually require you to handle the error. You can forget to handle the error, or forget to do a nil check. And Go won’t tell you until it crashes and explodes at runtime.

Technically the user’s fault, but good systems protect the users from their own mistakes.

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

#44

Post by sethammons »

eptcyka wrote: post #25
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.

If you are prototyping, assign unused to the underscore.

foo := thinger()

_ = foo # no longer unused

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

#45

Post by asdf88990 »

kajman wrote: post #27
logicchains wrote: post #16

Earlier quoted context omitted.

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.

That is just a silly rationalisation by primitivists, and they will never be able to articulate any rational point where abstracts makes sense, in their world, whatever Russ Cox and a bunch of Google employees deem fit is the ideal.

Even when Russ Cox and Go team had come to term with reality and stopped pretending like we are in 70s still, these lot will move goalposts. It is a kind of psychosis and sycophancy that is beyond rational discourse.

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

#46

Post by asdf88990 »

BobbyJo wrote: post #32
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!

Have you tried to read the Kubernetes or Docker codebases?

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

#47

Post by wannabe44 »

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.

In practice you use Go with a linter, so this is not a problem in practice. I have never seen a missed error.

The problem is painstakingly and manually having to build the stack trace, and then unwrapping it few layers above if you ever need to check what error it was.

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

#48

Post by akerl_ »

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…

This comment could make the same point and be even more effective if wasn't written as a snarky retort in violation of several of the guidelines of the site ( https://news.ycombinator.com/newsguidelines.html )

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

#49

Post by TheDong »

inigyou wrote: post #39
TheDong wrote: post #37

Earlier quoted context omitted.

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.

The more common steelman for go is "most programmers are idiots, so a language designed for idiots is a good tradeoffs since it's easier to hire programmers for a codebase in that language"

I think that one is true. Like, if you're building something that is able to be successful despite having a poor type system, frequent panics, and difficult to correctly use concurrency primitives, Go is a great language for letting the lowest common denominator programmer be productive.

If you're building more serious software, then it can be a very bad tradeoff that destroys your company or product, but you know, that's true of a bunch of languages.

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

#50

Post by mayama »

Someone wrote: post #23
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…

There are so many proposals for improving errors, even half implemented ones that are dropped. I even stopped checking pros and cons after a few. As ultimately everything got rejected and the message is that you have to live with verbose checking with llms now.
Post reply on HN