Really good read.
One thing they didn't cover was why the monorepo is so appealing to facebook
this post was submitted on 15 Jul 2024
61 points (93.0% liked)
Excellent Reads
1441 readers
4 users here now
Are you tired of clickbait and the current state of journalism? This community is meant to remind you that excellent journalism still happens. While not sticking to a specific topic, the focus will be on high-quality articles and discussion around their topics.
Politics is allowed, but should not be the main focus of the community.
Submissions should be articles of medium length or longer. As in, it should take you 5 minutes or more to read it. Article series’ would also qualify.
Please either submit an archive link, or include it in your summary.
Rules:
- Common Sense. Civility, etc.
- Server rules.
founded 1 year ago
MODERATORS
Our code base has grown organically and its internal dependencies are very complex. We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. On top of that, the idea that the scaling constraints of our source control system should dictate our code structure just doesn’t sit well with us.
This is from the blogpost it links near the beginning. Also worth a read if you're interested.
If I had to guess I'd say it's because fundamentally Facebook development is about deploying servers.
As you move through the main branch, at any commit, you should have something that you can deploy. The moment you split the repo you lose this, and need to worry about keeping multiple repos aligned.
I personally love a monorepo. It has to be managed effectively by the team, but the benefits are great. Most of it boils down to making more effective incentives for maintenance and care for downstream effects because "we all live here". There are tradeoffs and it's not for every situation or team though, for certain.
I’m not a programmer and don’t know how to use git, but at least have a basic understanding of what its use is. I think the Closing Thoughts has a pertinent lesson that’s much broader:
I’m reminded of the classic wisdom that so many of history’s key technical decisions are human-driven, not technology-driven.
Facebook didn’t adopt Mercurial because it was more performant than Git. They adopted it because the maintainers and codebase felt more open to collaboration. Facebook engineers met face-to-face with Mercurial maintainers and liked the idea of partnering. When it came to persuading the whole engineering org, the decision got buy-in due to thoughtful communication - not because one technology was strictly better than another.
They made a point of mentioning the clarity and extensibility of the Python codebase as well (not sure if it was the article of the original blog) as making it easier to modify. They could have forked the code if they thought git was clearly better.
I wouldn’t expect web devs to know C.
This guy's cute.
Never heard of Hg before? SVN? CVS? Clearcase? SCCS? SCCS++ like unix used? I understand if source code management seems a new skill since it's just been a part of devel for 40-ish years, but one writing about devel could get a handle on it first.
I stopped reading when he wrote "these asks" like "ask" was a noun used by someone writing seriously and not a car salesman. I guess one could "action" an "ask" about the "spend" while "doing lunch", as those all fit the 1984 sales-brody template.
I do not see what you mean by the second paragraph.
Complaining about ask as a noun, an innovation that only picked up recently, sounds like "old man yells at cloud". I do not get your association with some 80s salesman and have never seen such usage in any contemporary films. Also, how the heck is a blog post "someone writing seriously"?