The usual text editor features, like templates, reduce the typing, but the point is that the programmer must think, each time, about what they want to do when a function fails. This can become either a really good habit, or a distraction, depending on your perspective and problem domain.
When people say Go poor or no error handling, this is probably what they are complaining about. The fundamental properties offered by try/catch/throw are unpacked by Go into defer, recover and multiple value returns and type switches. Go's designers make the argument that when used thoughtlessly, exceptions encourages error handling antipatterns.
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.
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?
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:
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.
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.
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.
it's not there there's no error handling; it's that there's no exceptions. Instead, you use multiple return values, one of which is an error, and you check the return value for an error. It forces you to handle errors at the call site and makes diapers unimplementable.
> It forces you to handle errors at the call site and makes diapers unimplementable.
I don't see how the latter is true. What's the practical difference between wrapping a function call in a try/(no-op)catch and entirely ignoring the error return value?
If the function returns a useful value and an error then you'll have to assign to error to "_" to ignore it, which is a pretty big hint to the reviewer that it's being suppressed. So in cases where you want to "force" error checking, returning multiple values is probably good enough.
