Hacker News new | ask | show | jobs
by thijsvandien 311 days ago
Error(error) -> Error(error) has strong if err != nil { return err; } vibes, and I don't consider that a good thing.
3 comments

No, it doesn't have strong if err != nil { return err; } vibes.

Pattern matching on Ok/Error is one of the best known error handling, while go error handling is one of the worst. They are about as far from each other as possible.

Interesting, I find myself thinking the exact opposite.
That's what Gleam's use expressions[1] are for (the last example is exactly this case). Most languages with the same heritage as Gleam have grown a similar syntactical feature, such as OCaml's binding operators or F#'s computation expressions. Although I appreciate how simple Gleam's is while having similar power.

[1]: https://gleam.run/news/v0.25-introducing-use-expressions/

This is a trivial snippet. Often you will transform/map your error into another type (or deal with it in some way), so it's not so much `if err != nil { return err; }` vibes like you're thinking here.

The beauty here is being compelled to handle both the happy and sad paths. You cannot just pretend the sad path doesn't exist.

Good Go code also wraps errors...
It's not just about wrapping. use-expressions, result.try and result.map eliminate the boilerplate of checking for errors entirely: https://erikarow.land/notes/using-use-gleam
One man's boilerplate is another man's explicitness.