This one is specifically the assumed values of some types when declared in a struct or variable. Like, a struct with a string field gets an empty string value by default. I appreciate the reason for it; it just jars horribly with my expectations.

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.

I think the rationale goes something like this: how do you create a fixed size array? Of structs? Where one field is another fixed size array of timestamps? And on the stack?

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?

Array initialization is a bit awkward in Rust right now, it’s true. It’ll get much better in the nearish future.

Initially I found it quite baffling, that slices or hash tables don't need initialization to be valid, but long term, I find this brilliant. Especially for slices, that a zeroed out slice struct is a valid empty slice is very clever and simplle.

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.

Generics is only part of the issue. Go has a crippled type system.

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.

> Json in go cannot be represented as a type and also is not type safe.

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.