> `if err != nil` is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it

Haven't really used Go, but can't someone just `result, _ := foo()` and go on using `result`, not checking any errors?

The way Rust does it seems closer to forcing you to handle any errors in order to obtain the result (though it is still easy to just `.unwrap()` without properly thinking about it).

▲

therealdrag0 4 minutes ago | parent | next [-]

Personally, I don’t want to swallow errors I want to throw them. 90% of the time, I have a few small cross-cutting points (like an api controller) I want to catch and handle exceptions that get thrown from the rest of the code base.

▲

chuckadams 6 hours ago | parent | prev [-]

We do want to check for errors, we'd just prefer that it not be a repeated 3-line boilerplate pattern that ends up being >50% of all code. Rust does it with one character.

▲

Ukv 5 hours ago | parent [-]

I agree that Rust's approach is better. I'm questioning the claim that Go "forces you" to handle errors, since to my understanding with Go someone can just eschew that 3-line boilerplate, silently ignoring the error, and still use the result (which is bad).

▲

4ndrewl 5 hours ago | parent [-]

The point being that's how you've decided to deal with the error, by ignoring it.

	▲	Ukv 5 hours ago \| parent [-]
		Silently ignoring errors by leaving out some boilerplate doesn't really seem like an active/forced decision, or a selling point over the languages it disparages ("[...] hellscape doesn't make errors disappear, it just hides them"). Then that the correct path is the one of more resistance seems poor design, in my surface-level opinion.