Go Analysis Framework: modular static analysis by go team

Post by majormajor » Mon, Jul 27, 2026, 3:34 AM UTC

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…

Post by yoghurtwere » Mon, Jul 27, 2026, 4:32 AM UTC

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.

Post by yoghurtwere » Mon, Jul 27, 2026, 4:36 AM UTC

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.

Post by yoghurtwere » Mon, Jul 27, 2026, 4:56 AM UTC

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…

Post by TACIXAT » Mon, Jul 27, 2026, 5:11 AM UTC

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…

    log.SetFlags(log.LstdFlags | log.Lshortfile)
    // ...
    if err != nil {
        log.Println(err)
        return errors.New("Error doing the thing.")
    }