"BuildXL runs 30,000+ builds per day on monorepo codebases up to a half-terabyte in size with a half-million process executions per build... You may find our technology useful if you face similar issues of scale."
I know this wasn't supposed to be a humorous announcement but I couldn't help laughing out loud at that! Kudos to the managers at Microsoft who now seem to be asking "Why not?" instead of "Why should we?" when the topic of releasing code to the community is raised.
You'd be surprised at the volume of code a smaller company can produce.
Former employer was a big C++ shop in finance. Of around 1000 employees, roughly 3/4 of those were developers. They definitely could take advantage of something like this. I dont know how many 100s of million of LOC they have between C++ and later C#, but I was responsible for around 3 million alone (largely generated). A full coordinated firm wide rebuild could take weeks.
I've a similar story or three of finance companies that in just ten years produced enormous amounts of legacy code. It's really not that hard. Solaris was enormous too, with just 2k devs for all the time I was there, and about 30-40 years of history, depending on how you count it. If your 1k developers each write 10Kloc/year on average, then after a decade you can expect to have 10Mloc, but since a lot of code will be forked external open source (or even not forked, but just imported to freeze at a particular version, or for some other reason) you might find your devs building and looking after many tens more Mloc than that. If you hire lots of 5x and 10x engineers, that too leads to a sizeable increment.
There are many many companies out there that have huge megarepos.
Ok but, what's the byte size of 10MLoc, and how many process executions per build - since these were actually the metrics used. My experience is that lines of code don't actually take up that much space.
Depends largely on how the code is structured with C++.
There's the number of compilation units within a lib vs overall. Typically you can parallelize within a module, but not externally unless you have some smarts.
Edit: I use module in this sense as a producible result, not the future language concept of modules.
We (the developers) were tasked with enormous responsibilities. I was back office, but responsible for managing a client/server for all non security reference data. There were easily over 200 data objects modelled. No direct DB access was allowed except for the owning service. Although it ended up around 3M LOC, it wasnt as bad as it seems, because only about 10% was manually written code. A lot was generated C++ (and aside: I was able to write a C++ wrapper around a generic API that exposed some 300 types through a home grown reflection esque API amd the Python wrapper never had to be updated necause it could use this reflection and run time cose generation to generate a strongly typed API at
runtime; to my knowledge, the Python code has remained unchanged since about 2006 despite the underlying C++ API changing constantly, when I first wrote it - I get occasional updates from former coworkers).
The big problem was the dependency management and scale. At least at the time I was there, neither were done well.
Scale was a problem because of tight coupling between libs. Upgrade a core lib? Everyone had to rebuild. Want to upgrade a 3rd party dependency? Firm wide rebuild that took a min 2 weeks. It was a mess. We were supposed to be client/server to minimize dependencies, but we so tightly coupled our clients to our servers, we just exacerbated the problem. A few us could handle multiple client versions with a single server, but most couldn't. Don't recommend.
I agree with the other commenters. You'd be surprised how much code companies you've never heard of. I used to work for Axway, an enterprise middleware vendor. They had at least 3 products that I knew about with multi-million LOC codebases, in Java and C and various other languages.
I wouldn't be surprised if they had at least 50 million LOC in total. Actually, now that I think of it, 100 million was more likely. And that was almost 10 years ago...
I think the GP is more taking a jab at MS's history of being anti-open source, which has taken an about face in the last 5 years or so.
I mean we had Ballmer under whom you'd likely never have seen anything (or only trivial, non monetizable things) open sourced and likely no Linux support.
Now under Satya, we have MS open sourcing lots of projects and embracing Linux as a first class citizen. Probably far a complete list of Linux support, off the top of my I can name: VS Code, building for Linux via VS proper, Cmake support, WSL, SQL Server on Linux, SQL server odbc drivers, .Net Core and Linux support in Azure.
Even if projects are completely open, such as WSL and connhost, they have github projects at least for bug tracking that allows end-users to directly interact with the teams responsible for those projects. Personally, I've filed several issues against WSL and I've gotten fairly quick responses and resolutions usually appear in a few weeks time (I'm in the Fast Insider's ring at home).
I'm pretty impressed with WSL. I've just moved back to Windows (Dell XPS) after ~13 years using Mac OS, and in many ways WSL is nicer than what I used to do before with juggling Homebrew packages and Parallels VMs depending on the demands of a particular task. Between that, PowerShell, and installing stuff via Chocolatey, I feel right at home.
But without things like WSL and native OpenSSH, I doubt I would even have looked; I would have stuck with MacOS forever or just gone native Ubuntu.
Yes, it's on my list to check out! I just haven't yet found something I wanted to install that wasn't available in chocolatey—scoop's forte appears to be CLI utilities, and I haven't gotten as far into that realm.
Congratulations to the BuildXL team! Domino, incidentally, was/is the internal for BuildXL; there are a few papers published where the system is described under that name. I had the privilege to see it gradually rolled out in the Office codebase over the course of a year or two. It was a massive improvement, and the lengths to which the team went to see it through are really beyond description here.
I _have_ to wonder why we didn't just pick up Bazel, which is Google's open-source distributed build engine for large systems, which also happens to have been stable for years. Perhaps its Windows support wasn't up to snuff at the time, but it feels like that would have been easier to fix that than to build a whole new build system.
Regardless, congrats again! So cool to see this out in the open.
> I _have_ to wonder why we didn't just pick up Bazel, which is Google's open-source distributed build engine for large systems, which also happens to have been stable for years. Perhaps its Windows support wasn't up to snuff at the time, but it feels like that would have been easier to fix that than to build a whole new build system.
Bazel was first announced and made open-source in early 2015, but by that time Domino had already been in development for at least a year. I remember following the early internal discussions at Microsoft on the One Engineering System or "Apex" initiative which first provided the impetus for what became Domino; some of those discussions were quite animated :P
Also, while I don't know BuildXL and Bazel well enough to compare their goals and relative strengths, I will say that BuildXL was developed at Microsoft, which has historically had a great diversity of build toolchains and workflows across all its software products. Just on the toolchain side, Microsoft has many different build engines/make tools, unit test frameworks, tools and conventions to register an automated test to run on a certain schedule (for products too big to run every test on each and every build), build and test server farms, continuous integration tools to orchestrate those server farms, tools to email people and/or file bugs on test failures, and so on...
From my limited understanding, Google has never been this way at all, and so some of the lessons and ideas incorporated into BuildXL may seem strange to Bazel's designers.
Windows support in Bazel is still far from perfect; to this day, you need Msys2 for many things to work. Still, things have been moving forward quite a bit recently, I think in part due to Angular. Honestly, it's still really nice to use imo, but I can see why it would be hard for Microsoft to adopt.
(I work at Google and have contributed a very tiny bit to improving Bazel on Windows, though it is not related to my actual work at Google.)
You have to wonder though whether the effort spent building Build Accelerator would be better spent fixing Bazel bugs on Windows. Bazel really has no equal on the Linux side, and Google's internal version (+Forge and other systems) is far and away the best dev experience I've ever seen anywhere.
I do Maven for Java and JVM languages, Gradle only because Google forces me to on Android, for better or worse CMake has won for C++ and MSBuild for .NET languages.
I am yet to see what Bazel does better, beyond faster Android builds, which is quite easy given Gradle and how Android team implements their plugins.
I just started working at a shop that uses Bazel for a large-ish Java backend codebase.
So far the key differences from maven, which I am most familiar with, are:
* The module format is much lighter, making it more practical to split a project into thousands of modules, which can then be built incrementally. This leads not just to faster build times, but finer-grained tracking of dependencies between modules
* The driving factor for us: Bazel has built-in support for specifying the sha256 hash of external dependencies. Verifying authenticity of external dependencies is not possible in maven without significant extra work. In Bazel it's built in.
* Much easier to set up bazel targets to perform once-off tasks like seeding a local database through your build system. While can you can do this with maven, you usually had to resort to plugins and the declarative style made it complex. Most maven projects I worked on had external shell or python scripts for these sorts of tasks.
For me personally the biggest downside has been that it takes over enough of the build-system responsibilities in IntelliJ that other tooling I'm used to that integrates with the IDE, such as Chronon or JRebel, doesn't work.
Bazel has a steep enough learning curve and enough additional complexity that I probably wouldn't recommend it for most projects unless you are at a certain size and complexity level where you can benefit form it.
I love Bazel, but above all I hope open source can adopt Bazel more. It’s certainly much more usable for the case where you want to import external programs, versus systems like CMake, in my opinion.
Nix is similar to Bazel, supports distributed cache + build + CI (via Hydra), and has a huge amount of existing build support tools. It's not typically used as the only build system though; it's more like glue that wires all your build systems together deterministically. Build steps (derivations) are simple bash scripts executed within a sandbox.
The only catch is that while the language and tools are simple, Nix is really a pure functional language and you have to treat your build process like code rather than config. It's easy to go down rabbit holes...
(I considered Bazel but it's very half-baked and lacks all of Blaze's proprietary toolchain support.)
Bazel has not "been stable for years", perhaps you are thinking of "Blaze"? Bazel is full of brand new code and recent bugs (such as not releasing file handles) suggest it is not yet fully ready for mass adoption.
Seems what drove this was a 90 build times of 90 hours for and end to end build of Office. What I can gather this has a means of capturing all read/write operations for a build step and placing it in a cache store to determine if a change necessitates the rebuild of a component. Since it can hook in at a lower level, it isn't sensitive to time stamps for building. Actually quite interesting
“Its own internal scripting language, DScript, an experimental TypeScript based format used as an intermediate language by a small number of teams inside Microsoft”
I know this wasn't supposed to be a humorous announcement but I couldn't help laughing out loud at that! Kudos to the managers at Microsoft who now seem to be asking "Why not?" instead of "Why should we?" when the topic of releasing code to the community is raised.