> Finally, null pointer dereference does not cause undefined behaviour, as in C, C++. Go will panic (and you can safely recover). I'm not convinced that removing null pointers will eliminate the cause of these bugs. I think the idea of "failing fast" would help diagnose bugs much faster - although I see reasons for disagreeing.

Dereferencing nulls in Java is not undefined either, so what? And the notion of 'failing fast' is exactly why null pointers should be modeled in the type system. What faster way to catch bugs than at compile time? Furthermore, how do you know you will quickly hit a NPE in you code at runtime, if it happens to be in a code path that is infrequently accessed? Ironically in the OSCON talk mentioned in another comment here, Pike mentions that dynamic typing is pushing some compile time errors into runtime, which is exactly what is happening here.