Re:Gleam v1.12.0 Released
by thijsvandien on Wednesday August 06, 2025 @03:40PM
(#44816706)
Error(error) -> Error(error) has strong if err != nil { return err; } vibes, and I don't consider that a good thing.
[ Parent
| on HN ]
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.
Re:Gleam v1.12.0 Released
by samdoesnothing on Wednesday August 06, 2025 @05:19PM
(#44817982)
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
Re:Gleam v1.12.0 Released
by samdoesnothing on Wednesday August 06, 2025 @07:15PM
(#44818937)
One man's boilerplate is another man's explicitness.
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.