Hacker News new | past | comments | ask | show | jobs | submit login

How does a Result type making error handling easier? More reliable, sure, I buy that. But I write a bit of Rust these days, and error handling is definitely not easier. It's actually kind of an enormous pain in the ass, and it certainly seems to involve more lines of code than it does in Go (not just in my code, but in all the libraries I've read).



The most common thing you want to do with an error is bubble it up. IME Result types strike the least-bad compromise between making that too intrusive (if err != nil clutter) and making it too subtle (exceptions i.e. magic invisible control flow).

(I don't think Rust is the best example of result types; it's missing a lot of tools for working with them because Rust doesn't have HKT and functions aren't quite first-class because of their lifetime checker, so instead of using ordinary functions you end up using ad-hoc macros or language special cases like ?. Since Go is garbage collected they wouldn't have that problem)


I've not had that problem. I would love to see the question mark operator in go because I think it is an elegant way to avoid a ton of boilerplate while still remaining a tad explicit about where errors can occur.


Easier in that I don't have to force my team to use a static analysis tool just so people don't silently ignore errors.

CI works, but I have to set it up. For every project. And fix anything that was not developed with golangci-lint.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: