> The use of zero values is a crime against nature
Can you elaborate?
The worst offender is `Time` – to quote from the documentation:
"The zero value of type Time is January 1, year 1, 00:00:00.000000000 UTC. As this time is unlikely to come up in practice, the IsZero method gives a simple way of detecting a time that has not been initialized explicitly."
That seems to be an absolutely baffling decision.
Without some kind of default value, you end up with a lot of nested constructors and loops initializing array elements and fields, versus just zeroed out memory.
C++ does the constructor thing but it seems complicated and finicky when you don't have a zero-arg constructor. When I looked at Rust array initialization it looked somewhat limited, but maybe I missed something.
I'm not sure if every type really needs a zero value like in Go, but it seems like standard types like timestamps should, so you can use them this way?
I also don't see what your problem with time is. Zero is one set point in time. Not sure, why you want an "invalid" timestamp. Does make as little sense to me as an "invalid" integer. Why would you need to check that a time value has been explicitly initialized? And for most purposes, the zero value pretty much would express that anyway. If not, you can wrap the time value into a struct with a nonpublic initialized bool slot. But I really would like to know what your use case for this would be.
Json in go cannot be represented as a type and also is not type safe. This is 100 percent because go is missing a basic type primitive.
Json contrary to what many people think is not untyped. Json is represented by a recursive sum type which go has no ability to represent.
I think what caused this issue is more because the designers of go are more systems people rather than language theorists.
Not a Go programmer, but why don't you simply use an explicit type tag and a number of getters? They can assert that they're not called in invalid situations.