Everyone just keeps repeating the same old gripe, without bothering to read the responses.
Go needs a null-like thing because the language forces every type to have a zero value. To remove the concept of zero value from Go would be a major change.
The responses from Ian and the Go fans are not very well-thought.
To begin with, zero values were never a great idea. It sounds better than what C does (undefined behavior), but zero values can also hide subtle bugs. The correct approach is to force values to always be initialized on declaration or make use-before-initialization an error.
Having said that, it was probably too late to fix zero values by 2009, when Go was released to the public, and this is not what the thread's OP suggested. He referred to Eiffel, which is an old language from the 1990s (at least?) that didn't initially have null-safety (or "void-safety" in Eiffel's case), but released a mechanism to do just that in 2009, shortly after Tony Hoare's talk at QCon London 2009 (no idea if they were influenced by the talk, but they did mention the "Billion Dollar Mistake" in the release notes).
Eiffel's added nullability and non-nullability markers to types (called "detachable" and "attached"), but it's also using flow-sensitive typing[1] to prevent null-dereferencing (which is the main cause for bugs).
The thread OP didn't ask to eliminate zero values or nullable types, but rather requested to have a non-nullable pointer type, and flow-sensitive typing.
If structs need to be zero-initialized, a non-nullable pointer could be forbidden in structs, or alternatively Go could make explicit initialization mandatory for structs that have non-nullable pointers. At the very least, Go could support non-nullable pointers as local stack values, and use flow-sensitive typing to prevent null dereference.
If there's a non-nullable type, then there's types without zero values, and that means some basic properties of Go no longer hold. I don't know how many times that can be said differently. Whether something is in a struct or not is not relevant.
Uninitialized variables are zero. Composite literals may omit fields, and they'll be zero. Map accesses for nonexistent keys return zero values. Channel receives from closed channels return zero values. make returns zero-valued slices. Comma-ok style type assertions return zero values. Slices are fat pointers where the zero value avoids an allocation for data.
Now you're creating a flavor of types that cannot be used in many places. Or worse, a flavor of types that when added to a struct breaks existing uses. That'd be a major change.
Sigh. Yes, everyone knows what the goal is. But that goal is in conflict with the design decisions made in Go, and there's no clear path forward. You're not responding at all to the actual implications of types without zero values. There's no such thing as a "type that cannot be sent over a channel" or "a type that cannot be a map value" or "a type that when added anywhere in a composite type prevents omitting fields in composite literals" or "a type that cannot be comma-ok type asserted to". And it's highly unlikely such concepts will be added to the spec.
You'd have to start by constructing replacements for all those mechanisms, then migrate all Go source code in the world over to the new APIs, just to enable Go to have types without zero values.
Go needs a null-like thing because the language forces every type to have a zero value. To remove the concept of zero value from Go would be a major change.