Hacker News new | ask | show | jobs
by madeofpalk 500 days ago
I appreciate verbose and explicit patterns like this, but what go lacks is the algebraic data types/enum/unions to actually make this more ergonomic and checked.

I find it bizzare that go so strongly relies on this pattern, but lacks the features to make sure you actually check for errors.

2 comments

Im not really following this. Only somewhat familiar with Go.

The pattern we're talking about is returning errors and having to explicitly check for them, right? How does the lack of "algebraic data types/enum/unions" make this pattern un-ergonomic?

Error patterns aren't type checked in Go. So you can forget to check an error, not notice, and ship a bug. It compounds with features like zero values and pointers-as-null to make these bugs either subtle or not subtle, but discoverable only at runtime.
> So you can forget to check an error, not notice, and ship a bug.

How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation.

If you forgot to document that feature in your tests, which is more likely, then you've created a situation of undefined behaviour, not a bug. You've made no claims as to what should happen. All possible behaviours are equally valid.

And no, pattern matching doesn't help you here as you still need to document what happens on those pattern matches. If you forget to document these cases you've still got the very same undefined behaviour. There is no escaping the need for the tests.

It's cool that there is nicer syntax, that your editor can warn you of mistakes while you are typing, and that can save time and all that don't get me wrong, but this idea that you are going straight up forget without any notice of your forgetfulness, as fun as a trope as it is, just isn't realistic.

> How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation.

> ... this idea that you are going straight up forget without any notice of your forgetfulness, as fun as a trope as it is, just isn't realistic.

By forgetting. Copying `if err != nil` is a mundane and repetitive process, it's easy for your brain to go into auto-pilot.

> And no, pattern matching doesn't help you here as you still need to document what happens on those pattern matches. If you forget to document these cases you've still got the very same undefined behaviour. There is no escaping the need for the tests.

Pattern matching (with algebraic data types/enum/unions) helps because it forces you to check the error. It becomes impossible to use a return value without checking the error.

> By forgetting.

Like in the same way you might forget to write pattern matching code? I mean, that's possible, but the checks and balances are going to let you know. In light of that, what is the significance of forgetting for the few seconds, if that, before getting notified of your forgetfulness? That's not a real problem.

> Pattern matching (with algebraic data types/enum/unions) helps because it forces you to check the error.

Checking the error alone is pointless. You need to also do something with the error, and pattern matching does nothing to help you with that. But that's what tests are for, there to help you with exactly that.

And since your code needs the right branching strategy to get to the point of doing something with the error as validated against the documentation, you also know that your branches are present and working as documented. You cannot possibly forget them after applying the checks and balances. How could you?

All you can really forget to do, maybe, is to document what the program is supposed to do. But in that case the program isn't supposed to do what you forgot to add anyway. Anything missed is undefined behaviour. If you have forgotten to consider what you want your program to do, no language can help you with that!

In Go you can forget to call a function with the correct arguments, and it will not compile, right?
> Like in the same way you might forget to write pattern matching code?

This is a lengthy response to seemingly ignore, or miss, the point being made.

It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. Conversely, it is possible and easy with Go.

Nothing you have said acknowledges this.

You "can" forget to check an error, but in practice I've never seen it happen. The error check always happens after it is assigned so a missing check stands out like a clown at a funeral, and as a bonus there are linters that check for missed errors, which is trivial due to how Go and Go errors work.
100% this. The idea is ok, the tooling to actually use it is terrible