When I started writing my entry on why it matters that map values are unaddressable in Go, I expected to end it with a remark to the effect that I didn't understand why the Go authors had put this restriction in the specification but they probably had good reasons. But by the time I finished writing the entry, I had realized the language semantics problem of allowing 'm["nosuchkey"]' to be addressable. Then later when I looked up how Go maps store their values (and keys) I saw how allowing you to take the address of a map value probably wouldn't do what you wanted in natural Go.

I've had this experience more than once, where I've been surprised by how quietly careful Go's design and specification is. There are various technical areas of the Go specification that have had what seemed like arcane restrictions or rules, but when I've thought more deeply about them I've come up with reasonably good reasons for the rules to exist.

(Sometimes these are small ones, like how arbitrary precision constants affect cross compilation. Even things like always requiring delimited if blocks have reasons.)

On the one hand, this shouldn't be surprising in general. The designers of Go were quite experienced, knew what they were doing, and spent a fair amount of time working on it. Given that, it's very likely that everything in the Go specification was carefully considered and has a solid reason behind it, even if it's not immediately obvious.

On the other hand, this is not necessarily the usual experience with languages, especially languages that haven't gone through a formal (and somewhat adversarial) specification process. Solid language specifications are genuinely hard to create and you don't see them very often.

PS: This isn't to say that Go's design and specification is flawless, even apart from features it simply doesn't have. I haven't gone looking for flaws, but they probably exist and people have probably written about them.