5 ms·

For everyone who complains about monorepos, remember some of the most forward thinking engineering companies like Google and FB also use monorepos. All the argu

For everyone who complains about monorepos, remember some of the most forward thinking engineering companies like Google and FB also use monorepos. All the arguments that people make in favor of polyrepo are making so because of lack of strong tooling for monorepos. That's also why Google and FB would not have scaled if they were using GitHub / GitLab but had to build their own. Also Google's original source control was built on top of perforce!

hbrn 4y ago
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.
fargo 4y ago
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.
- phyrex 4y ago
  how so?
threeseed 4y ago
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.
afavour 4y ago
> 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.
scarmig 4y ago
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.
- andromeduck 4y ago
  Would be nice if google3 as a service were a thing.
  - JTBooth 4y ago
    google3 and Plex! God how I miss working with Plex, I didn't know how good we had it.
    - 8n4vidtmkvmk 4y ago
      Plex the home media server, or something else?
      - deleted 4y ago
        [deleted]
      - Rastonbury 4y ago
        I think it's an internal Google tool
- hbrn 4y ago
  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.
slotrans 4y ago
Ah yes, the old "if FAANG does it, it must be right" argument. You love to see it.
- tourist2d 4y ago
  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.
- qznc 4y ago
  Amazon does polyrepo by the way. Unfortunately, they don’t talk about it.
deleted 4y ago
[deleted]
agos 4y ago
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?
- Shish2k 4y ago
  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

hbrn 4y ago

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.

fargo 4y ago

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.

phyrex 4y ago
how so?

threeseed 4y ago

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.

afavour 4y ago

> 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.

scarmig 4y ago

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.

andromeduck 4y ago
Would be nice if google3 as a service were a thing.
- JTBooth 4y ago
  google3 and Plex! God how I miss working with Plex, I didn't know how good we had it.
  - 8n4vidtmkvmk 4y ago
    Plex the home media server, or something else?
    - deleted 4y ago
      [deleted]
    - Rastonbury 4y ago
      I think it's an internal Google tool
hbrn 4y ago
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.

slotrans 4y ago

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

tourist2d 4y ago
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.
qznc 4y ago
Amazon does polyrepo by the way. Unfortunately, they don’t talk about it.

deleted 4y ago

[deleted]

agos 4y ago

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?

Shish2k 4y ago
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