Twelve Years of Go

Re:Twelve Years of Go by uncomputation on Wednesday November 10, 2021 @08:21PM (#29183330)

Go’s error handling is a strange this to praise considering it is entirely possible to ignore it without warning and the way to check error kinds was bolted on through type assertions when errors are supposed to be values in Go. Error kinds are important especially in network programming when the error can be dozens of different things. Compare this to something like Rust or Haskell which force you to handle errors and their variants.

[ Parent | on HN ]

Re:Twelve Years of Go by Thaxll on Thursday November 11, 2021 @09:41AM (#29188283)

Once again Rust does not force you to handle errors, you can ignore errors in Rust and it will compile. I can't say for Haskell but I doubt there is a language that forces you to handle error.

let _ = openFile()

Error ignored, it does compile, it will probably ends badly.

As for network error: https://pkg.go.dev/net#OpError

[ Parent | on HN ]

Re:Twelve Years of Go by Karrot_Kream on Thursday November 11, 2021 @12:15AM (#29184670)

Pretty much every form of Go tooling warns you when you ignore an error. If you only choose to run "go build", yes you can ignore it, but a simple "go vet" call and it'll be plain as day.

[ Parent | on HN ]

Re:Twelve Years of Go by kamaal on Thursday November 11, 2021 @01:32AM (#29185077)

Certain things need to be available out of the box.

The whole point of a programming language is to make the programmers life easier.

By now decades of exposure to programming languages have made try/catch the standard way of working with errors. Forcing the programmer to guess issues, when the compiler/runtime could be doing it- IMO is just plain waste of human labor. And for even medium to large applications is a pointless exercise.

[ Parent | on HN ]

Re:Twelve Years of Go by azth on Thursday November 11, 2021 @01:00AM (#29184909)

    a, err := foo() // oops, unhandled error
    err = bar()
    if err != nil { ... }

    fmt.Println("...") // oops, unhandled error

or more insidiously

    err1 := foo()
    if err1 != nil { ... }
    err2 := bar()
    if err2 != nil { return err1 } // oops

[ Parent | on HN ]

Re:Twelve Years of Go by Karrot_Kream on Thursday November 11, 2021 @01:25AM (#29185039)

In the first and the last case, it seems obvious to me where the error is. An obvious code smell caught in review. The second error, yeah, but lots of languages don't enforce error handling around printing to stdout, and even though Rust does in theory, in practice everyone just unwraps it and moves on with their day.

[ Parent | on HN ]

Re:Twelve Years of Go by azth on Thursday November 11, 2021 @01:47AM (#29185147)

> but lots of languages don't enforce error handling around printing to stdout

They do, they throw exceptions.

> In the first and the last case, it seems obvious to me where the error is

The last case is especially insidious. I've seen it in production several times now. Very easy to miss. Particularly when refactoring/copy pasting code (which you have to do a lot of in golang).

[ Parent | on HN ]