The issue with building a custom monorepo system that can handle Google's and Facebook's scale is that it fails to scale down, even to moderately large project and organizational size. It's expensive (think at least 7 figures opex) and not what most people should be doing.

git, for all its issues (and I'm a git-hater), scales down to an individual coder and scales up (with a lot of hacks, the hacks being used varying depending on whether you're taking a poly or mono approach) to companies that employ thousands of developers.

Would be nice if google3 as a service were a thing.

google3 and Plex! God how I miss working with Plex, I didn't know how good we had it.

Plex the home media server, or something else?

I think it's an internal Google tool

Polyrepo scales to thousands coders without anyone even noticing, and that's the beauty of it.

Just look at the size of node_modules in an average project. You stand on the shoulders of thousands of other engineers and you don't even think about it. That's your polyrepo at work.

Now imagine that every time a dependency wants ship a new version, their maintainers have to update all of the dependents. That's your monorepo.

It is quite obvious which one is more scalable.

The only real benefit monorepo has is that every dependency is always at it's latest version. But the cost to achieve that... let's just say there's a reason you mostly hear about monorepos from Google.

> remember some of the most forward thinking engineering companies like Google and FB also use monorepos

As a counterpoint though I’d say that the issues Google and FB face, particularly in terms of the sheer scale of the work they’re doing, is pretty unique.

Google literally invents programming languages for domains it feels needs them, I’m not about to blindly follow that practise either.

They way at least FB is using a monorepo is very different than any kind of monorepo most people imagine. It's not just about tooling, git itself could never handle it. I am all about using a monorepo but Google and FB having one is not the an argument for it.

how so?

a) There is no correlation between mono/poly repos and your ability to scale. There are many examples of successful companies using either approach.

b) As a general rule people should be cautious about adopting approaches and technologies from Google, Meta without a clear understanding of why they need it. What works at their scale doesn't always apply to smaller teams.

Ah yes, the old "if FAANG does it, it must be right" argument. You love to see it.

That's not what they said at all. You love to see people unable to read a couple of sentences before jumping to their own conclusion.

Amazon does polyrepo by the way. Unfortunately, they don’t talk about it.

For anyone who complains about dictatorships, remember some of the most resource-abundant countries are dictatorships.

Those companies should be one of last places to look for good software development practices. They have absolutely no incentive to recognize their own mistakes.

didn't meta need to switch to mercurial and a custom extension for it because they were not able to make it work with git?

IIRC originally neither mercurial nor git would scale enough, but mercurial was much more willing to accept scalability-related patches, so long as they didn’t harm the more common small-scale use-cases. After a couple of years of submitting patches for moderate improvements, meta wanted to make some more controversial large-scale changes like dropping support for sequential commit numbers, and ended up hard-forking and breaking compatibility to do that. That incompatible-but-better-performing fork then stayed internal for a while, before recently being released as Sapling.

As a bonus, part of the rewrite of the internal storage engine involved creating a storage engine abstraction layer, which in turn made it easy to add Git as a backend :D