PCHs give a sour taste in my mouth after working on a project which very liberally added commonly imported headers to a huge one. In practice, it meant each TU was indirectly including many more headers than needed, and it was harder for humans (or IDEs) to reason about the real dependency chain. While builds were faster, they also started using much more memory.
You also can end up needing to rebuild the world, if touching a header that is part of the PCH, even if it isn’t really needed by all the targets.
Modules and header units were supposed to solve these a lot more cleanly, but is still not well supported.
A company using React Native recently used bounties to solicit bug-fixes to RN issues their app was hitting.
A lot of positives came out of it, and it did improve framework quality. There are challenges with the model though. More changes than not are high quality, but some aren’t, or are just inherently risky, and it’s especially tricky to discern when first time contributors touch systems that might no longer have an active maintainer. Unlike someone employed full-time, there isn’t the opportunity to establish long term trust, and the contributor might not be around to support their change if something goes wrong.
A lot of changes fell through the cracks, or needed maintainer time that wasn’t there, which creates a bad situation where someone could have done great work, but isn’t getting paid. Knowing that someone is losing money if you don’t accept a PR can also trend towards guilt-inducing as a maintainer.
Worth pointing out, there has been quite a bit of contention around this change, both technical, and some accusations of plagiarism/miscrediting here. https://github.com/ggerganov/llama.cpp/pull/711
It's a good question well above my pay grade :). Changing culture isn't an easy problem.
I suspect the way Microsoft does interviewing and performance management (very local to the specific team) contributes to the inconsistency.
MSFT has also been fairly open to its employees that it does not try to compete with competitors like Google, Meta, or even Amazon, in terms of compensation. So it isn't really trying to get the best engineers, so long as it can continue to print money.
There are still folks there who are incredible, but the floor is shockingly low at times. Folks will self-select, so you will then get teams which are more homogeneously good or bad.
I previously worked at Microsoft in an unrelated area, but had a friend who worked on CosmosDB, and later a different part of Azure.
There are some Microsoft products I genuinely love, but some are terrible. To an extent it is a reflection of the inconsistency in internal teams. Culture, values, skill level, and quality bar are all over the place depending on who you talk to, even compared to other large companies.
From what I had heard, CosmosDB was not a healthy team, and I would not consider using it as a product.
I haven't touched Ruby in a while, but are there any common multithreaded use cases? It seemed like the direction was to go multi-process for web workloads (E.g. with Unicorn).
Microsoft internally uses something pretty similar to Bazel. I'm not familiar enough with the two to fully understand motivations for the divergence. It supposedly initially ran poorly on Mac, just due to differences in what is cheap on different platforms. I wonder what kind of inherent performance differences you would find in something "Windows first" vs "Linux/MacOS first"
https://github.com/microsoft/BuildXL
I until very recently worked on Microsoft Word. The whole problem gets even more complicated when you add support for richer content like formatting, images, comments, etcetera. Sprinkle in requirements for things like three-way merge, simultaneous editing from multiple authors, undo behavior on top of that, and the amount of cross-cutting complexity for something seemingly simple can be absolutely astonishing.
Another benefit of deterministic builds is that build output caching becomes more reliable. Microsoft has a system used for this that is heavily used internally that was recently open sourced: https://github.com/microsoft/BuildXL/blob/master/README.md
I work on Office and am glad someone brought up this point. Writing a C++ business logic layer is probably too much for a simple CRUD style app, but the equation changes once the view/platform layers are a tiny minority of the logic in your app.
I’m a bit surprised Chrome developers went the route of an in memory filesystem instead of trying to sandbox and clear real disk access. Silently using up to 120MB without realizing sounds pretty bad.
I've been in Seattle for around a month and can completely agree with this. One time half of an order went to a wrong apartment, and the other half came the next day. UPS and related have access codes to get into the building where Amazon doesn't. Having free same day delivery is a life-changer, but Amazon needs to improve a lot.
I've worked on Office. There's a ridiculous amount of effort put into file format backwards compatibility. Someone I know had to consider Office 2007 compatibility when working on a feature within the last year.
I find it alarming, and somewhat ironic, this article was removed from HN temporarily for it being repeatedly flagged. I don't fully agree with the article, but using a mechanism to prevent abuse to hide an opinion that you disagree with is akin to the forms of censorship net neutrality is meant to prevent.
I interned at MSFT working on Word. Engineers and PMs in Office see a lot of opportunity in AI. PowerPoint Designer and the newer ML based proofing in Word are good examples of things that have already shipped. I never saw anything resembling a war.
You also can end up needing to rebuild the world, if touching a header that is part of the PCH, even if it isn’t really needed by all the targets.
Modules and header units were supposed to solve these a lot more cleanly, but is still not well supported.