←back to thread

Buck2: Our open source build system

(engineering.fb.com)
392 points mfiguiere | 2 comments | 06 Apr 23 16:05 UTC | HN request time: 0.414s | source
Show context
phendrenad2 ◴[06 Apr 23 21:48 UTC] No.35474996[source]▶
> Build systems stand between a programmer and running their code, so anything we can do to make the experience quicker or more productive directly impacts how effective a developer can be.

How about doing away with the build system entirely? Build systems seem like something that shouldn't exist. When I create a new C# .NET app in Visual Studio 2019, what "build system" does it use? You might have an academic answer, but that's beside the point. It doesn't matter. It just builds. Optimizing a build system feels like a lack of vision, and getting stuck in a local maxima where you think you're being more productive, but you're not seeing the bigger picture of what could be possible.

replies(14): >>35475210 #>>35475243 #>>35475249 #>>35475260 #>>35475271 #>>35475272 #>>35475320 #>>35475645 #>>35476535 #>>35476550 #>>35477035 #>>35480031 #>>35485001 #>>35487462 #
kristjansson ◴[06 Apr 23 22:21 UTC] No.35475320[source]▶
If you look around the toolbench, and you can't figure out who the build system is ...
replies(1): >>35476193 #
phendrenad2 ◴[06 Apr 23 23:53 UTC] No.35476193[source]▶
Why should I care what the build system is? Please use your words.
replies(1): >>35477747 #
kristjansson ◴[07 Apr 23 03:37 UTC] No.35477747[source]▶
Sure:

Whatever code we write as developers is only very tip of a the iceberg of software that comprises any substantial application. Controlling what goes into that iceberg, and how it's assembled is an essential part of the engineering of software. The details and quality of your build system determine the composition and construction of that iceberg, not to mentioned the reliability and velocity of your development process.

Even 'basic' local build systems like CMake, maven/gradle/ivy, sbt, lein, cargo, go, ... bridge dependency management and task execution. They decide what goes into the software artifact you ultimately distribute (or deploy), and how that's assembled.

At the scale of buck, bazel, ... tools of that shape are necessary to make forward progress in that's composed of internal dependencies that are managed by different teams, written in different languages, targeting a variety of environments, that are so numerous they require distribution to complete in reasonable timeframes, and require absolute.

I'm not VS/C# user, but MSBuild is definitely a build system, and both in and the developer definitely have care about these complexities, even if they come under the heading of "IDE" instead of "Build System".

Also:

As the joke in my first comment implied, if you can't identify the build system, you're probably the build system

replies(1): >>35479447 #
phendrenad2 ◴[07 Apr 23 08:19 UTC] No.35479447[source]▶
I'm starting to understand. This is a problem at FAANGs, and I simply haven't worked at a FAANG.
replies(2): >>35481807 #>>35482181 #
1. ahslian ◴[07 Apr 23 14:17 UTC] No.35481807[source]▶
(Note: I work at Meta, on the buck team)

This isn't really just a FAANG thing. I've seen this throughout my career before the FAANGs at much smaller places, but projects needing multi-platform/multi-language/multi-arch scenarios.

You do have a point, that the issue is that one shouldn't have to learn the depths of a build system to do what one needs. The trade off is how are the knobs exposed to a developer.

Another way to think about it, these domain specific languages like Starlark and otherwise are just where the knobs are being stored. As much as Visual Studio ends up writing these to vsproj/vcproj or msbuild files, it's just that these are stored in another form.

replies(1): >>35486363 #
2. phendrenad2 ◴[07 Apr 23 20:06 UTC] No.35486363[source]▶
To clarify, I don't think that complex build systems are only used at FAANGs, I think that their usefulness is only realized at FAANGs. From what I've seen at smaller companies, most people are using these tools because everyone else does, not because their software production suffers from the kinds of problems that these tools solve. These tools also seem to provide the mental framework that people need to think about their software production processes, so I guess there's that.