Hacker News Reader

Comment by totallysnowman | Hacker News Reader

I think that the reason of the argument is that both authors understand the definition of "large repository" very differently.

With 100 engineers a monorepo might seem a good idea. With 500 it becomes nearly impossible to do anything involving a build. Some isolation is needed.

Also from my experience many engineers just don't give a shit about architecture. They create entangled mess, that kind of works for the customer, and go home. Without some enforced isolation it is impossible to maintain it.

That being said I am more inclined to polyrepos.

View on HN

the fact that essentially 100% of big tech companies use monorepos seems like evidence that it is at least possible to do it in a scalable way...

yeah by writing custom version control software. Am I going to convince my company to do that (which has like 50k software engineers) probably not.

How many companies have 50k software engineers? Seems like the handful that do, should do whatever works for them. The rest of us can just use a monorepo.

Amazon does not use a monorepo, so you might want to rethink your "statistic".

Definitely not 100%. It also has a lot less to do with company size, and more about when the company was created. Before the git and similar tools of the world came to be, managing a single repo was a pain, nevermind hundreds or thousands of them. So (almost) everyone did it the way these big companies did.

Today, not quite. I work for a multi billion dollar tech company and we have several thousand repos (and it's awesome)

Not true. Google, Facebook, Goldman Sachs and JP Morgan, all companies that run mono repos and predate git by very far.

Git cannot checkout sub directories and it slows down exponentially with the number of branches. It's the opposite of what is needed to run a mono repo in a large company.

My wording must have been awful...because that's exactly what I was trying to say.

The big companies that predate git and such used monorepos because that was the norm at the time, and it was easier to do with the tools at the time, and as they scaled, they just scaled their process instead of changing everything. But several large tech companies, especially newer ones, do the multi repo approach.

AMZN doesn’t, unless things have changed drastically in the last 3 years.

> With 500 it becomes nearly impossible to do anything involving a build.

Both FB and Google have more than 500 devs and are using a monorepo.

At what cost? Both FB and Google employ hundreds of devs to work on internal tooling only. For most companies this isn't feasible.

Afaik, fb employs less than 20 people to take care of the monorepo.

It's actually the other way around. The cost of dealing with all the downsides multiple version control systems is way higher than investing in tooling for the Mono-Repo. This is mentioned in articles by Facebook and Google.

Source? Sounds like you're pulling that number out of thin air.

Isn't it reasonable to assume that FB/Google will do a cost analysis of mono/poly repo approaches and pick the one that is the most cost effective? At that scale they have absolutely no room for dogma; it's all about costs.

Why does the build not work at 500 engineers? Just because there are 5 apps / services and their 25 libraries doesn't mean you have build the 4 other apps when doing development just because you did a git pull. Libraries would still need to build their dependants in a CI system with poly or mono repos.

The 5 apps and their 25 libraries are in fact one entangled monolith. That is what I am talking about. It is only marketed as 5 apps. That has some hundreds external dependencies, of course.

Reply on news.ycombinator.com