No thanks.

I programmed for Android back in the 1.1 days. I'm pretty familiar with the problem of lots of creating lots of small objects. That problem is now effectively solved on the newer versions of Android, due to Dalvik updates. I feel confident that Go will tread a similar path.

> 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.