I don't know that you can just add compile time nil checking to go and still retain everything else. It seems to me - although I could be entirely wrong - that

I don't know that you can just add compile time nil checking to go and still retain everything else. It seems to me - although I could be entirely wrong - that the mindset that produces this kind of idea ("nil pointers are teh devil!") is incapable of producing the kind of experience that Go produces with its toolchain (trivial cross-platform compilation, etc). Again I can't prove it, but it just seems that way. For instance, if you believe nil pointers are the devil and you should statically enforce checking them at compile time, it seems that it would only be natural that you would also think the following other things are very important to be enforced at compile time: - Read-only references - Move semantics - And all the related baggage What does this have to do with compile times and cross compilation? Maybe not much, but time and attention are limited resources, and when you focus on concepts typical related with "nil pointers are evil" you take away precious resources that could otherwise have been dedicated to building the kind of developer experience that Go provides.