Hacker News Reader

Comment by dhconnelly | Hacker News Reader

Go doesn't "lack error-handling." They're referring to the fact that Go doesn't have exceptions; you check return codes to detect and handle errors. For some this is tedious, but has advantages (mentioned in the article) with respect to understanding an entire program.

View on HN

The problem is it's no better than C - the correct way is to return sum types, either values or errors. A good language would statically check that any returned values are only used when there are no errors, preventing invalid values being accessed.

This requires some flow analysis, but brings real benefit and safety.

It is considerably better than C, in that you can return multiple values. A common approach is to return two things: the data result of the function, and a error-indicating bool or int. Checking the error flag right at the call is very easy to read and understand, though some feel the code gets verbose. I feel that the execution path is easier to understand this way than with exceptions ("goto considered harmful").

C's multiple-arguments-but-only-one-return-value always was a bit weird. Does anyone know how C's authors decided on this feature?

    The problem is it's no better than C

Multiple return values are pretty clearly better than C. The comma-OK or comma-err idiom is verbose, but powerful and unambiguous.

A well known and tested approach, sum types (tagged unions), would have been way better, but it was cast aside because the designers were apparently unaware of the improvements to union types made since C's inception:

http://www.reddit.com/r/programming/comments/w1ig0/things_i_...

There is no reason for any new language to lack tagged union types. It disturbs me that Brian Cox rejects a simple, proven language feature that he does not even understand, even though it would take all of 2 minutes of searching/reading to understand. I'm sure he spent at least that long composing the replies in that thread, never moving past the ego-threat of "will Go ever have X?" to honestly evaluate the question.

"There is no reason for any new language to lack X" is false for all X. Languages differ in their goals, and there's no feature that all languages have to have. Even basic features like assignment can be questioned.

*Russ Cox

You're jumping to a false conclusion that Go's designers were not aware of those language features, and that that was the reason why they aren't in Go.

Care to give an alternative explanation to the contents at the other side of the URL I gave?

You said that sum types were omitted from Go because the designers were not aware of more recent developments. That's not true. They were omitted because they do not mesh well with the other features of the language, such as zero types, interfaces and embedding.

Whether you agree with that latter point is moot. Go's designers were and are fully aware of sum types; they chose to omit them from Go for a reason, not because they were ignorant of their existence.

Sum types are conceptually cleaner but it's unclear to me how they would help with analysis for this case. I don't know about formally, but informally, it's easy to determine by inspecting the code that a function returns either a value or an error, even it's written as a tuple. It's also easy to determine whether the call sites are handling errors correctly.

yeah, sum types are my #1 missing feature in go. i'm excited that mozilla's rust has decided to add them.

Reply on news.ycombinator.com