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

71–80 of 100 posts

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

#71

Post by [deleted] »

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.

[deleted]

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

#72

Post by aaa_aaa »

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

When I moved from Kotlin to Go because of a job change. it was painful. Apart from its runtime benefits, it is overrated IMO. it lacks basic conveniences. Go is not a simple language, it is a primitive language.

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

#73

Post by rowanG077 »

bayindirh wrote: post #70
rowanG077 wrote: post #68

Earlier quoted context omitted.

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…

Are you really being so obtuse? Of course in real code you might use the error. For printing, forwarding it to a logging frame or anything else. The point is the error does not guard access to the return value. Here basically the same example:

package main

import ( "errors" "fmt" )

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

func main() { msg, err := getMessage() fmt.Println(msg) fmt.Println(err) }

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

#74

Post by thiht »

asdf88990 wrote: post #46
BobbyJo wrote: post #32

Earlier quoted context omitted.

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?

Kubernetes is a behemoth, but the Docker (Moby) source code is actually pretty easy to get into (if you're already a Docker user and understand how containers work)

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

#75

Post by inigyou »

TheDong wrote: post #49
inigyou wrote: post #39

Earlier quoted context omitted.

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

Go is a great language for when you want to just accomplish some server-side business logic with minimal bullshit standing between you and it.

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

#76

Post by asdf88990 »

thiht wrote: post #74
asdf88990 wrote: post #46

Earlier quoted context omitted.

Have you tried to read the Kubernetes or Docker codebases?

Kubernetes is a behemoth, but the Docker (Moby) source code is actually pretty easy to get into (if you're already a Docker user and understand how containers work)

If you think Docker code is easy to get into then you haven’t seen clean code.

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

#77

Post by akerl_ »

kubb wrote: post #60
akerl_ wrote: post #48

Earlier quoted context omitted.

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 )

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

Nobody is suggesting uncritical praise.

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

#78

Post by hoppp »

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…

1. There is nothing stopping you from implementing a Contains function.

2.That error handling is one of the best features. It makes me explicitly acknowledge the errors instead of letting them just happen. No error goes unnoticed!

Each if err != nil is an explicit reminder to check, do I need to clean up? Do I need to log this error to a file?

"And no more oh an error happened I wonder where"

With LLMs verbosity is not an excuse anymore. Just generate it and focus on other things then

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

#79

Post by bborud »

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…

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), staticcheck, gosec and test. And that’s the “light” build that doesn’t run leak analysis, fuzzing, race testing, benchmark regression and integration tests in addition. The light build is still faster than the Rust compiler. I haven’t compared the heavier build.

When people pretend the absence of features is a huge problem, I tend to think that these are people who either aren’t regular Go users or perhaps they are more interested in debating languages than writing code.

Let’s not pretend this is something it isn’t.

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

#80

Post by bborud »

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…

I think the examples are both bad along different axis. One occupies more lines, the other results in _more_ and uglier syntax. They’re both bad. So the question is which axis is worse.

While the first occupies more lines I suspect I’d spend less time spotting it in the code. The physical shape of the expression is something my brain is used to seeing after 40 years of programming. Even when code grows more complex.

The second is OK when it stands alone, but I am not so certain it would be as easy to spot in more complex surroundings. Even on a single line, there is something a bit ugly about the code. Even before we get to the desperate triple-pipe. That kind of reminds me of the desperate attempts at repairing JS after they realized its equality semantics were shot. Just heap more characters on it.

The thing is: it is actually very hard to judge how ergonomic a language is by just looking at it. You have to use it and you have to use it enough to realize where the paint points really are. I’ve read through a lot of the responses in this discussion and I’ll be honest: I think a lot of people who criticize other languages (be they Rust, C, Go or whatever) aren’t very fluent in them. It takes a couple of years to develop fluency.

Post reply on HN