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.
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.
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.
At Meta many engineers tried management and then went back to being an individual contributor. I'm not sure of the exact numbers but it was a very common career path. It did build up empathy for management on the senior IC side and meant that teams didn't get stuck with managers that didn't actually want to be a manager. If the company is not growing headcount this move makes perfect sense.
A question to answer: is the enjoyment coming from actually being the machinist, or is it coming from assembling something you designed? The answer could be either. But if you just want to bring something you designed to physical fruition and you are limited on space then I would recommend finding machine shops that will make what you design for you. This is what Protolabs, Shapeways, Xometry, etc do. You don't need to actually have a 3D printer or laser cutter or CNC mill to get things built. You can probably find a local fabricator too. I found a guy that made handrails and would do random welding jobs, I used to go to his shop for all sorts of different things. Even if you get the money and space to build out a shop, there's a lot of skill to these crafts and people dedicate their whole career to becoming experts in them.
I do not think the outcome is only Uber / Lyft but with AI, but if that is the outcome I still think it would be a win. Today supply of Uber / Lyft in my area at off hours is spotty, and that makes it unreliable. I have gotten stuck walking home 2+ miles multiple times in the last year because I couldn't get a ride at any price. That's not a problem in Manhattan, but not everywhere is Manhattan. Driverless cars would be on 24/7/365 so wouldn't have that problem. The more reliable these taxi services are, the more viable it is for people to get rid of their cars.
I also expect long term self driving cars will be safer than humans, and as a person that primarily walks around instead of driving that's a benefit to me even if I'm not in the car.
For many years my "big question" has been "why do software engineering projects fail at a disproportionally higher rate than other engineering fields?"
Though I have to say the other engineering fields are not doing so hot lately either, so I might have the wrong question.
I'm not at all interested in finance / stock picking but found this to be one of the best walkthroughs of an ML system end-to-end that I've ever read. I'm not in the field of ML but I'm interested in learning more and this was fantastic, thank you.
As an owner of a vacation home and a large donor to homeless charities: this is completely divorced from the reality on the ground. It's a false dichotomy proposed as a way to block solving the problem of limited housing where it's acutely needed.
My ski house in Vermont does absolutely nothing for the homeless people in my neighborhood in New York. If you put someone in that ski house what would it do? Sure it would put a roof over their head, but there are no jobs, no soup kitchens, no homeless resources. They would need a car whereas in New York they can walk and use mass transit. The town in VT is already strapped supporting many in their community (I do charity there as well, and let me tell you it's more dire than much of the New York area).
The solution is to house them here in the New York area where they are (and in fact New York does a better than average job of this).
As for it being a misallocation, I own a $1M apartment in NYC and a $300K house in Vermont. If I just owned a $1.3M apartment in NYC my bills would be exactly the same, there would be 1 fewer "vacant house", and the homeless would still be unhoused. The real misallocation is how much I get paid as a software engineer relative to other professions of similar difficulty. I happen to spend my fun money on a ski house instead of a boat or a bunch of vacations, but there's no moral difference between a vacation home and other leisure spending. So really you are arguing that some people shouldn't have such a surplus when there are homeless people. Maybe that's true, but it's one of the most unpopular positions in American politics and if you are an ally of the homeless it's not a fruitful argument to make.