Hacker News Reader

Comment by Sytten | Hacker News Reader

TLDR a dev forgot an if err != nil { return 0, err } in some critical service

That is still the most bizarre error handling pattern that is just completely accepted by the Go community. And after a decade of trying to fix it, the Go team just recently said that they've given up.

It's not that bizarre, it's exactly how errors used to be handled in older languages like C. Golang is not strange, it's just outdated. It was created by Unix greybeards, after all

I guess "bizarre in the 21st century" would be more accurate.

More critically, some service allowed for unvalidated instant rollout of policy changes to prod. The actual bug in the code is largely irrelevant compared to the first issue.

Processes and systems have flaws that can be fixed, humans always will make mistakes.

Does the Go compiler not force you to handle errors

It doesn't exactly, no. There are linters and a compiler-enforced check preventing unused variables. Overall it's pretty easy to accidentally drop errors or overwrite them before checking.

So no, it doesn't.

Well at least you shouldn’t be able to actually dereference a nil, right?

Sadly, and imo almost unforgivably in such a modern language, no

fwiw Go is simple, can be easily translated from TypeScript thanks to how similar it is, and has a GC, so you don’t have to learn what the hell a borrow checker is

You'll get a runtime panic.

Hey, it's better than lurking undefined behavior and data corruption issues!

Doesn't keep your binary from crashing, though.

No language forces to handle errors. Even Rust.

> No language forces to handle errors. Even Rust.

It does. If a function returns a Result or Option type, you can't just use its data; you have to either automatically propagate the error case upward, pattern match on both the success and error cases, or just use ".unwrap()" and explicitly choose to crash in the case of an error. There's no implicit crash like there is in a language that lets you dereference null pointers.

let _ = works fine in Rust.

That still can't cause a null pointer dereference.

Probably C++ or java though.

Reply on news.ycombinator.com