No thanks.

> Go doesn't differ much from C wrt. to error handling. Except that in
> C I know that -1 is always -1 or 0 is always 0.

This is really unfair. Numeric types are strongly typed in Go.

Also, in C, 0 may not always be 0. Technically pointer NULL is a logical representation, not a physical one, so casting a NULL value for a pointer to an int may result in something other than 0. As someone invoking the name of Haskell, you should know this :)

No real-world C compilers that I know make use of this liberty. As usually, C++ "outdoes" C in the amount of implementation-dependent crud. Specifically, NULL values for pointer to member functions are usually not represented by the bit pattern 0. Check this out for some nifty implementation dependent spew:

#include <stdio.h>

class Foo {
int i;
};

static union {
int Foo::*i;
void *v;
} u;

int main(void) {
u.i = 0;
printf("iPtr = %p\n", u.v);
return 0;
}

I agree that the way in which interface values are compared to nil in Go is a little weird. Since the interface types are represented by a tuple internally, it would have been nicer to force developers to write out that tuple when comparing an interface to a constant.

We are going to have to agree to disagree about error handling. I could point out a lot of other notable programmers who prefer error codes to exceptions, not just Joel Sposky. From the Google C++ coding standard, to Raymond Chen, to Linus Torvalds. But what do those guys know anyway? Java checked exceptions are the way and the light (hint: they're not.)

Comparing Go and Haskell is comparing apples and oranges. Go isn't intended to be a functional programming language. We already have a ton of those already (OCaml, Scala, Clojure, etc.) Maybe for algorithms work it's good, but for systems-level work I think those are all very uninteresting.

I have found that in practice the moment one wants to add more context to errors the good old return flags to indicate unexpected return status results in least cluttered code.

For example, in Java stack traces in log files by themselves can be rather useless for problem diagnostics. To facilitate the analyzes it is often necessary to log state information from quite a few call sites. But in Java that results is rather ugly

try {
code();
} catch (RuntimeException ex) {
log_extra_error_state();
throw ex;
}

With return error codes the extra clutter is minimal - one just needs to add log_extra_error_state(); on the error path.

Now, I presume in Haskell such annotated error reports should be rather simple to implement using Either. But even in Haskell checking for errors after return is inevitable if one wants to add the context information only on error paths.

This certainly raises the bar to fully understanding the behaviour of exception using code.

Here's what he said:

"I think the reason programmers in C/C++/Java style languages have been attracted to exceptions is simply because the syntax does not have a concise way to call a function that returns multiple values"

Notice that's he's talking of the *syntax*, and functionally the tuple-unpacking that some languages allow do come close to being equivalent to being able to return multiple values.

handle, errcode = open('blah.dat')

This is prettier than the all-too-common functions that do things like "this function will return the count of Widgets, or -1 if something went wrong", also it's less error-prone because with the above you can't accidentally treat an error_code as valid data. (and proceed as if there where really -1 Widgets, say)

Also why do you consider returning a tuple different from returning multiple values?
The only thing that matter is allowing the programmer to have a readable way to access multiple return values ( y,z = f(x) ), whether these return values are in a tuple or not is not so important, thought I would argue that the tuple is better as it also allow f(g(x)) so it's better (provided it still allow the simple access to the multiples values).