Hacker News Reader

Comment by Analemma_ | Hacker News Reader

> Speaking of not having maybe/option, every other line of code is "if (err == null)" and there's no way to abstract this out. Give me `option` dammit.

This is why I can't take Go apologists seriously when they say the language is just fine without generics. Ok, fine, maybe I don't need generics in my application code as much as I thought, but their absence has cascading effects throughout the language and requires you to do ridiculous things all over the place. Not just the constant "if (err == null)" and interface{}, but also go-generate, which I have seen Go defenders seriously try to claim obviates the need for generics. What?!

View on HN

There are definitely legitimate use cases for generics, but `if err != nil` isn't one of them. You'll simply be pattern matching on an option type instead. Go generate is definitely not a substitute for generics.

> You'll simply be pattern matching on an option type instead.

If you have multiple things that can fail in sequence, you can "lift" into option and then the result of your expression will either be a real result or a short-circuited error.

https://drboolean.gitbooks.io/mostly-adequate-guide/content/...

Or just use exceptions. Either would be preferable to C-style error handling.

> If you have multiple things that can fail in sequence, you can "lift" into option

Hey, look, a monad! \o/

Although I prefer exceptions, I like the way Rust approaches not having them.

It also communicates exceptions via option types, and - by convention - functions that can go wrong return an instance of Result<SuccessType, ErrorType> initialized either with a success value or an error value.

There are some helper methods on Result. I like "expect", which panics if an error is indicated and returns the success value otherwise. The real boilerplate removal comes via try!, which returns the result (actually it re-wraps it in a new Result) if it's an error. When used on functions that can fail inside functions which return Result, the result is that try! bubbles the exception up the stack.

The experience is very like traditional exception handling, but you always know exactly how control can flow, since try! only returns from the function it is directly inside, and can only from functions which advertise that they can fail by having Result<> as their return type.

Yeah, ultimately it's fundamentally no different than Go but with more sugar and ability to abstract properly. Turns out that counts for a lot.

> If you have multiple things that can fail in sequence, you can "lift" into option and then the result of your expression will either be a real result or a short-circuited error.

How is that different than with error return values?

> Or just use exceptions. Either would be preferable to C-style error handling.

I disagree. Exceptions seem to hide the problem. In Java and Python, I see people consistently fail to handle exceptions properly. The error paths are neglected because exceptions "hide" them. I would rather have a correct program with verbose error handling than a program that only has an elegant happy path but is otherwise incorrect.

> How is that different than with error return values?

Compare: https://gist.github.com/nickretallack/1462f2652cda6fc2a97283...

If you can find a way to improve these code samples, please suggest it.

> Exceptions seem to hide the problem.

I haven't used Java in a while, but I recall a feature where it would force you to handle exceptions. It knows what kind of exceptions a function can throw, and it can check if they are exhaustively handled throughout the program.

Isn't the comma ok the recommended syntax for error checking?

I suppose if you want to write your code in a series of if-statements that march to the right like Node programmers complain about.

Reply on news.ycombinator.com