> When YOU instantiate the class, you are creating a THING. No. You are instantiating a type of a thing. But, in the real world, a thing can be more than one t

> When YOU instantiate the class, you are creating a THING. No. You are instantiating a type of a thing. But, in the real world, a thing can be more than one type. Often it is sufficient to approximate the real world by assuming that one thing is only one type, but as you have found out that doesn't work when your program needs to see one thing as more than one type (e.g. an egg can be both a type of animal and a type of food). A programming language that has a concept for both "things" and "types" is interesting, but no language that you would write production software in today has such a concept I'm afraid. > I'm just using models of the world to show you how stupid go is. Go has its faults. Many of them. But it lacking features to allow you to paper over stupid design decisions I'm not sure is one of them. The problem here – and the problem with a lot of Go criticisms you find here, it seems – is that you haven't fully thought through what you are trying to do. A well conceived model of the world would not leave you with a circular dependency here. But I understand the appeal of trying to take the lazy route, minimizing the model to the smallest thing that makes sense to your internal monologue. It is certainly less typing to have just one egg type that you use for every conceivable egg use, whether it contains a chick, what you scramble for breakfast, and the chocolate delivered by the Easter Bunny. The good news is that there are many languages that are chock full of features to allow you to hack that in. If Go is not the right tool for the job: Great!