You don't make breaking changes. You provide the new API and the old API at the same time, and absorb the additional complexity as the library owner. Best case scenario everyone migrates to the new API and eventually remove the old one. This sounds onerous, but keep in mind at a certain scale there is no one commit in production at any given time. You could never roll out an atomic breaking change anyway, so going through this process is a reflection of the actual complexity involved.
> if you can't have one commit in production at any given time
That might be possible in a simple library + 1 consumer scenario if you follow the other commentors' recommendation to always update library + consumer at once. But in many cases you can't, anyway, because you're deploying several artifacts or services from your monorepo, not just one. So while "1 commit in production at any given time" is certainly neat, it wouldn't strike me as the primary goal of a monorepo. See also this discussion about atomicity of changes further up: https://qht.co/item?id=44119585
> what advantages for the monorepo remain?
Many, in my opinion. Discoverability, being able to track & version all inter-project dependencies in git, homogeneity of tooling, …
See also my other comment further up on common pains associated with polyrepos, pains that you typically don't experience in monorepos: https://qht.co/item?id=44121696
Of course, nothing's free. Monorepos have their costs, too. But as I mention in the above comment and also in https://qht.co/item?id=44121851, a polyrepo just distributes those costs and makes them less visible.
Because they make more money using their servers for their own products than they would renting them to other people. Meta has an operating margin of 41% AFTER they burn a ton on Reality Labs, while AWS has a 21% margin with more disciplined spending. Social media is a more profitable business than infrastructure.
> Advertising (over 97.8% of revenues): the company generated over $131 billion in advertising, primarily consisting of displaying ad products on Facebook, Instagram, Messenger, and third-party.
That's not universally true. The sewer system in my town was overbuilt in anticipation of a development that fell through. That's why sewer / water bonds are typically up for vote separately from property taxes because there's such an interplay with development.
Huh? You have to pay property taxes now and those could end up being too high for subsequent generations to afford. That happens all the time and is a common reason why property gets subdivided. This is simply a question of whether the value of structures on that land should be included.
If anything a pure land value tax should be more predictable than a property tax, I got hit with a major property tax increase and looked into it, the town had calculated the new property tax based on an incorrect square footage and number of bedrooms for my house. After filing an appeal and going to court I got it fixed, but that was a more capricious process than if it was simply based on the value of the land under the house.
I would heavily consider this type of system once build times become a major pain point. That often happens somewhere around 20-50 people working in one codebase. So I think this is a problem space for medium sized companies. Truly small companies probably don't need this and should use the standard ecosystem tools, BUT if your team knows how to use it there's little downside in started from a Buck / Bazel. Especially since you get most of the benefit if you have a nice clean DAG of your modules, and that's easy to build at the beginning and hard to refactor into later.
IMO one of the nice things about Buck or Bazel is that once you learn it, switching languages doesn't require you to learn a completely new tool. Obviously the cost of learning it the first time is high and if you are used to one ecosystem may not be worth it. But I'm now on my 3rd different ecosystem that uses Buck/Bazel (Android, iOS, C++) and it's nice to not worry at all about the underlying tools.
It's honestly hard to measure at the scale of Meta. Just making everything compatible with Bazel would be a non-trivial undertaking.
Also that seems an interesting thing an independent person could write about, but whatever claims Meta made on a topic like that would be heavily scrutinized. Benchmarking is notoriously hard to get right and always involves compromises. It's probably not worth making a claim vis a vis a "competitor" and triggering backlash. If it's significantly faster than Bazel that will get figured out eventually. If not the tool really is aimed at Buck1 users upgrading to Buck2 so that is the relevant comparison.
At the time that FB started writing Buck, Bazel was not open source. I believe it did exist as Blaze internally at Google before FB started writing Buck. Facebook open sourced Buck before Google open sourced Blaze as Bazel.
Over time Facebook has been working to align Buck with Bazel, e.g. the conversion to Starlark syntax so tools such as Buildozer work on both systems. I believe Buck2 also now uses the same remote execution APIs as Bazel, but don't quote me on that.
