food.go and cow.go do not belong in the same (sub)module, IMO. That said, each team (and project) have unique sensibilities - consistency and familiarity help h

food.go and cow.go do not belong in the same (sub)module, IMO. That said, each team (and project) have unique sensibilities - consistency and familiarity help here. My gut feeling is that the "belongingness" of feeding a cow is closer to the cow than the food, unless your food.go is full of "GiveFoodToCow(), GiveFoodToChicken(),...GiveFoodToX()" which is gross. With that complexity, you're better of with a Feeder interface and implement Feed() in cow.go (and chicken.go, etc). If you cannot distill the logic to a single interface, you're probably better off with a receiver (or regular) function in cow.go, because having a list of GiveFoodToX() with different args in food.go is the worst possible design you could go with. > And would having a 1 file per module paradigm have made go any more complicated? I was being facetious. Under normal circumstances, no one should use one file per module in Go, but if Rubyists are feeling home-sick while writing Go, the option is available to them ;)