Not a googler, but at my company this has not been the case. We use several programming languages and some of the people driven choices (rather than technical n

Not a googler, but at my company this has not been the case. We use several programming languages and some of the people driven choices (rather than technical necessities) have lead to all the languages being twisted into an odd hybrid of the dependency management style of each other. Things are very complicated to manage and some teams are trying to leave their current and best known language for a language with internal champions/leaders that are louder, more opinionated, and better positioned politically. A lot of this is due to a lack of wide familiarity with intermediate git skills and a fear of learning the tool. So many of our solutions to this problem are to automate things under the rug, which is why every language ends up being handled generically using medium grade internal tooling instead of best of class industry standard tooling. Most of these issues can be boiled down to an avoidance of pain rather than a championing of the best technical choice. Ultimately no decrease in dependencies have been made. Projects are barely bundled together any more than before. The only thing that’s made that possible has been Docker and Docker Compose, and our monorepo strategy makes it more difficult to build images due to its size and our topical file systen layout making it almost impossible to check out only the parts of the repo you need. The monorepo itself may be a good idea but it’s no silver bullet. I’d say it’s one of the worst choices we’ve made due to the cultural impact it’s had. In our case I think we’d be better off with small monolithic repos due to a lack of proper training around how to manage either many small repos or a large monorepo.