if you think this way about go, you probably have a REALLY good team that can design in a really proper, DDD-ish way (in that case, go en masse to google asking for your hard earned 500k TC, since even google has confusion on the best way to structure go projects) or you simply program toy stuff/basic integrations which boils up to a map from a type to another. go doesn't scale to huge codebases in normal teams.
otoh, you are totally right about the 8 layers deep root functionality, but that IMHO reduces to mindless application of textbook oop patterns to applications (I still have to see a company randomly "changing databases" so the 8 layers of abstraction over the db are correct).
still, I adhere to a lost standard these days, which is less code as possible. golang is automatically disqualified since it thinks that a 8 LoC for loop with temp variables is "simpler" than a .map(fn) (so much for "throwing boilerplate away"). it likes to introduce point of failures, and I dislike point of failures