[madeofpalk]

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

[bborud]

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.

[madeofpalk]

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.

[bborud]

You rarely get anything for free.

Look at exceptions in Java, for instance. In theory the mechanism is there to guarantee that errors will be handled. In practice there are multiple schools of thought — several of which purposefully circumvent this mechanism by throwing runtime exceptions because they think checked exceptions just leads to a lot of unnecessary work.

It has been too long since I used Java to remember all the arguments for and against. But I do remember trying multiple approaches and realizing that only using checked exceptions turned out to be a bit too inflexible. That there were legitimate reasons to use runtime exceptions.

Go’s type system is probably “good enough”. Sure, I’d love to have option types and results. And it would have been nice to move some of the things in vet, lint, staticcheck into the compiler. But in _practice_ separating them is actually beneficial. Because it allows you to trade build speed for security. For instance when you are making a tiny change and you just want to make sure it still builds. That’s a _practical_ tradeoff you could not have made if the compiler were always strict.

One thing I wish Go would have adopted is Javadoc-like comments with explicit markup to document parameters, return values and possibly panics. Those were _more_ useful in practice than exceptions in Java because you could force people to be more deliberate when designing “contracts”. When I did Java we used to have the build fail if classes and methods did not document all params, return values, exceptions etc.

I also taught people to write unit tests while _only_ looking at the Javadoc for what they were testing and notating at the code. Even after years of doing this, I’d regularly find that implementations didn’t behave as documented when writing tests. This made people care about interfaces/seams/APIs/contracts and spend less time obsessing over having the compiler save them from sloppiness. It put the developer in the driving seat rather than have them run behind the compiler and just nudging things into a state where it compiles. It helped people think more about why something failed from a design point of view rather than put all their faith in the tooling.

I think that’s the biggest mistake of Go: it doesn’t care about documentation and to the extent it does, it introduces really, really stupid, pointless formal rules that does nothing to help developers.

[majormajor]

It's not hard to ignore an error in Rust, IME?

Especially as someone who's read a lot of code written by newcomers to Rust.

[yoghurtwere]

.unwrap()

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

[rowanG077]

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.

[bayindirh]

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

[maleldil]

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.

[rowanG077]

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"

[bayindirh]

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

[rowanG077]

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

[bayindirh]

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.

[vander_elst]

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.

[bayindirh]

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.

[vander_elst]

We can have the same argument about memory unsafe languages: "it should be the programmer that checks that the memory it's accessed in a safe way and not the machine"... and yet after many years and legions of programmers not being able to stop themselves creating memory leaks, we created memory safe languages and we advocate for their usage.

I hope it's clear that what was proposed above is just a toy problem to show the issue. In complex parts of the code, unfortunately, these errors sometimes happen. That's a fact.

A programming language should actually try to protect you from some logic errors. This is why have we programming languages in the first place. Otherwise why bother with garbage collection, types etc? Should we just use assembly then for maximal flexibilty and putting all the burden on the programmer?

[madeofpalk]

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.

[bayindirh]

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.