←back to thread

392 points mfiguiere | 1 comments | | HN request time: 1.739s | source
Show context
phendrenad2 ◴[] 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 ◴[] No.35475320[source]
If you look around the toolbench, and you can't figure out who the build system is ...
replies(1): >>35476193 #
phendrenad2 ◴[] No.35476193[source]
Why should I care what the build system is? Please use your words.
replies(1): >>35477747 #
kristjansson ◴[] 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 ◴[] 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. kristjansson ◴[] No.35482181[source]
Software scales up in the size of the iceberg of your deployment, and out in the number of teams working on it. Buck (and bazel and pants) solve for scaling both directions at once.

Whether you should care about the details and knobs of your build system is strictly a function of the first kind of scaling. Every team building software of appreciable size should think a bit about their build system, and even small teams might benefit from Buck or friends if their iceberg is big enough.