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

61–70 of 100 posts

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

#61

Post by rowanG077 »

yoghurtwere wrote: post #54
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…

.unwrap() https://www.reddit.com/r/programming/comments/1p0srgs/commen...

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.

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

#62

Post by stefr- »

yoghurtwere wrote: post #55
resonious wrote: post #38

Earlier quoted context omitted.

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

https://www.reddit.com/r/programming/comments/1p0srgs/commen...

You pasting this comment link on all the replies clearly shows you don't understand what actually went wrong in this Cloudflare outage. But Rust bad.

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

#63

Post by pjmlp »

asdf88990 wrote: post #45
kajman wrote: post #27

Earlier quoted context omitted.

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

Even the 70's, that is ignoring what was happening with CLU, Smalltalk, Mesa, Modula-2, PL.8, ML, ...

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

#64

Post by bayindirh »

madeofpalk wrote: post #42
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…

> 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 declare err as "_", which I call IDGAF placeholder, and this is a deliberate choice to ignore that variable. So you willingly and knowingly ignore the error variable.

Otherwise Go won't give you Go ahead.

Seriously, try to compile the example I have given. It's fresh, so hold with mittens.

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

#65

Post by bayindirh »

wannabe44 wrote: post #47
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.

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.

You don't need a linter. Practically Go code will not compile without declaring and using the "err" returning from a function call.

I have written a fresh example at https://files.bayindirh.io/misc/error_example.go. Give it a Go. ;)

OTOH, gopls is a great LSP, though, and it warns you about this immediately.

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

#66

Post by bayindirh »

rowanG077 wrote: post #61
yoghurtwere wrote: post #54

Earlier quoted context omitted.

.unwrap() https://www.reddit.com/r/programming/comments/1p0srgs/commen...

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.

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

#67

Post by comex »

bayindirh wrote: post #65
wannabe44 wrote: post #47

Earlier quoted context omitted.

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.

You don't need a linter. Practically Go code will not compile without declaring and using the "err" returning from a function call. I have written a fresh example at https://files.bayindirh.io/misc/error_example.go . Give it a Go. ;) OTOH, gopls is a great LSP, though, and it warns you about this immediately.

The problem is that this stops working once you have multiple assignments to err in the same function.

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

#68

Post by rowanG077 »

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.

Did you ever use go?

``` package main

import ( "errors" "fmt" )

func getMessage() (string, error) { return "DO NOT INSPECT", errors.New("something went wrong") }

func main() { msg, _ := getMessage() // Ignore the error. fmt.Println(msg) } ```

Compiles normally and prints "DO NOT INSPECT"

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

#69

Post by bayindirh »

comex wrote: post #67
bayindirh wrote: post #65

Earlier quoted context omitted.

You don't need a linter. Practically Go code will not compile without declaring and using the "err" returning from a function call. I have written a fresh example at https://files.bayindirh.io/misc/error_example.go . Give it a Go. ;) OTOH, gopls is a great LSP, though, and it warns you about this immediately.

The problem is that this stops working once you have multiple assignments to err in the same function.

Good point, but I personally never do that? Instead of doing (expensive) calls, I just assign the result to a variable and use that instead. Accessing to memory is pretty cheap in Go, and it's cleaned once it goes out of the scope, so why not?

Considering some expensive Go calls do the same caching underneath, this is the preferred design pattern, I assume.

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

#70

Post by bayindirh »

rowanG077 wrote: post #68
bayindirh wrote: post #66

Earlier quoted context omitted.

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

Did you ever use go? ``` package main import ( "errors" "fmt" ) func getMessage() (string, error) { return "DO NOT INSPECT", errors.New("something went wrong") } func main() { msg, _ := getMessage() // Ignore the error. fmt.Println(msg) } ``` Compiles normally and prints "DO NOT INSPECT"

> Did you ever use go?

Don't make me spit my tea. That monitor is expensive. Of course, yes: https://git.sr.ht/~bayindirh/nudge

Jokes aside...

You used "_" to ignore the error variable, which I call "IDGAF" placeholder.

So, you willingly ignored the error and tell me that you don't have to check the error? You told the compiler that you don't care about the error explicitly (via "_"). That's on you then.

In my first comment I noted in the P.S. section:

    ...if you ignore the error, this is a deliberate choice and the burden is on the developer.
You used "_" knowingly. Compiler/linter didn't add it there by itself.

I mean, do you even read the language documents to understand how a language works?

Post reply on HN