We're going to have to agree to disagree on this. imho, which is shared by many, many features that Go lacks in the name the name of "YAGNI" are actually because the Go team is too myopic to recognize that their minimalist ideals don't always survive contact with real world use cases. As developers, we have a few choices. The first is to not use Go. For folks working in the cloud native space, where Go is the lingua franca, this is not always an option. The second would be to throw caution to the wind and accept that your code won't be as clean, defensive, or idiot-proof as you could have made it with another language. Third is to use the features the langaues does have (as I've done here) to work around those it lacks. To be fair, there are times when I do choose no. 2. Fundamentally, it depends on what my expectations are in terms of _someone else_ using the package I'm working on. If some type _needs_ to be initialized to a certain state and that type is not exported or the package is internal, I may not bother with the approach I have outlined here. If, on the other hand, I expect someone else to instantiate variables of that type, I cannot run the risk that they fail to initialize it correclty. All things are relative.