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

81–90 of 100 posts

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

#81

Post by vander_elst »

bayindirh wrote: post #64
madeofpalk wrote: post #42

Earlier quoted context omitted.

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

Here's an example file: https://files.bayindirh.io/misc/error_example.go I have commented inside the code, but to recap here: - If you don't declare err variable, the code won't compile. - If you don't use err variable, the code won't compile again. So, you need to both declare and use the err variable to be able to compile the code. So you can't forget. Your code will not compile. The only way to "forget" is to decl…

If you have

``` a, err := f() b, err := g() if err != nil {} c:=a+b ```

The language will happily build and run, even though it should prevent to let you shoot in the foot.

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

#82

Post by kubb »

akerl_ wrote: post #77
kubb wrote: post #60

Earlier quoted context omitted.

I think the GP deserves the snark. Uncritical praise of everything about a language isn’t intellectual curiosity.

Nobody is suggesting uncritical praise.

> I love everything about go

That’s a total statement, not leaving any room for criticism.

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

#83

Post by bayindirh »

vander_elst wrote: post #81
bayindirh wrote: post #64

Earlier quoted context omitted.

Here's an example file: https://files.bayindirh.io/misc/error_example.go I have commented inside the code, but to recap here: - If you don't declare err variable, the code won't compile. - If you don't use err variable, the code won't compile again. So, you need to both declare and use the err variable to be able to compile the code. So you can't forget. Your code will not compile. The only way to "forget" is to decl…

If you have ``` a, err := f() b, err := g() if err != nil {} c:=a+b ``` The language will happily build and run, even though it should prevent to let you shoot in the foot.

Intentionally ignoring errors or explicitly not handling them are logic errors. No programming language shall protect you from them.

In a little blunt form: This machine has no brain, use yours.

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

#84

Post by bayindirh »

resonious wrote: post #38
bayindirh wrote: post #36

Earlier quoted context omitted.

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

While I have my opinions on manual memory management, I'll not open that file today (well, it may leak).

On the other hand, Go explicitly warns and tries to prevent you from ignoring or not handling possible errors. This is a bit different than a happy C compiler which doesn't warn you about leaking memory.

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

#85

Post by vander_elst »

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

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

#86

Post by madeofpalk »

bborud wrote: post #79
madeofpalk wrote: post #42

Earlier quoted context omitted.

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

I agree with you that it would have been nice with Result and option types in Go. But as someone else pointed out, unhandled errors are very rare in practice in Go because every Go project tends to use static code analysis tools that catches this. When people talking about things blowing up during runtime I can’t help but think that they can’t be serious Go users. On every build I generally run vet, lint (revive), st…

I'm actually not all that fussed about Result or Option types. I don't mind Go's approach to error handling. I think it should just have language/analysis features built it to ensure that you do it 'correctly', so things don't blow up if you do not remember a part of the system ("this value is sometimes nil") or you forget to do something.

The fact that external tools exist that "every Go project tends to use" to fill common a gap in the type system indicates to me that maybe the language itself could be improved.

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

#87

Post by madeofpalk »

bayindirh wrote: post #83
vander_elst wrote: post #81

Earlier quoted context omitted.

If you have ``` a, err := f() b, err := g() if err != nil {} c:=a+b ``` The language will happily build and run, even though it should prevent to let you shoot in the foot.

Intentionally ignoring errors or explicitly not handling them are logic errors. No programming language shall protect you from them. In a little blunt form: This machine has no brain, use yours.

It seems like an innocent mistake to me. I think there's a difference between actively ignoring something (like assigning an error to _), and ignoring something through omission. I think computers should try and prevent mistakes.

Go errors if you try to assign a number to a string, so it's clear there is some intention for the machine to catch when your brain makes a silly mistake.

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

#88

Post by bayindirh »

madeofpalk wrote: post #87
bayindirh wrote: post #83

Earlier quoted context omitted.

Intentionally ignoring errors or explicitly not handling them are logic errors. No programming language shall protect you from them. In a little blunt form: This machine has no brain, use yours.

It seems like an innocent mistake to me. I think there's a difference between actively ignoring something (like assigning an error to _), and ignoring something through omission. I think computers should try and prevent mistakes. Go errors if you try to assign a number to a string, so it's clear there is some intention for the machine to catch when your brain makes a silly mistake.

I don't know how other developers think while coding, but if something can error out, I always handle the error first, or at least insert a panic() or equivalent immediately before continuing coding, regardless of the language I'm working on.

I can also think a couple of cases where I deliberately catch the error, but don't do anything on it explicitly, esp. if I'm talking with a buggy hardware. I'd still log the errors as INFOs or WARNs though. I have seen too many "task failed successfully" errors in my life.

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

#89

Post by b7e7d855b448 »

vander_elst wrote: post #85
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 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?

Also not adding every single feature that could be nice is a good thing to me. Yes, there is a lot of syntactic sugar you could add, but this just ends up in even more debates and in the end it doesn't matter that much. There is a very clear path how to achieve regular things in go and that works fine for now

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

#90

Post by maleldil »

bayindirh wrote: post #66
rowanG077 wrote: post #61

Earlier quoted context omitted.

Unwrap is an explicit action. Checking an error is usually just forgotten. No unwrap can enter your code without the dev being accutely aware of it.

Your Go code won't compile if you don't check the error, though.

It does if you reuse the error variable, which is very common. Example: https://go.dev/play/p/ofL2fG-OIcC

This can't happen in Rust.

Post reply on HN