6 ms·

I find declarative build systems end up pretty frustrating in practice. What I want from a build often isn't the artifacts, but the side effects of producing th

I find declarative build systems end up pretty frustrating in practice. What I want from a build often isn't the artifacts, but the side effects of producing the artifacts like build output or compilation time. You get this "for free" from an imperative tool, but represents a significant feature in a declarative system that's usually implemented badly if it's implemented at all. The problem gets worse the smarter your tool is.

thfuran 2y ago
>What I want from a build often isn't the artifacts, but the side effects of producing the artifacts like build output or compilation time You frequently build things not to get binaries but to spend time compiling?
- AlotOfReading 2y ago
  The point is that there's often no way way to express "I want side effects" in declarative tools, and the number of side effects that might be useful is vast. For example, sometimes I profiling the build times to see where I should focus effort. Sometimes I want to see it to quickly check for issues where adding some dependency header causes build times to explode 100% in downstream dependencies during cold builds. Another common occurrence for is trying to debug a platform, toolchain, or standard library issue and the build system either doesn't detect changes in those components or only makes the components readily accessible in an internal cache that's subject to invalidation issues. You'll usually get the wrong artifact or test results in those cases. Some other systems (e.g. bazel/blaze comes to mind) actively try to hide side effects like stdout. In all of these cases, the only way to actually get these side effects is to reach into the tool's internals by blowing away caches/output folders or reading live log files. That's a failure of the build tool.
  - MereInterest 2y ago
    I haven’t used it, but it sounds like make’s —-assume-new flag does exactly what you want for the first part. It lets you rebuild everything that would result from a changed file, including all side effects, without needing to first update the file.
    - AlotOfReading 2y ago
      --always-make/-B is more in line, but yeah. Make has grown imperative models within its vast declarative morass.
    - eru 2y ago
      Alas, Make is really, really awful in most other respects.
      - PittleyDunkin 2y ago
        Really? It's the one part of the traditional c build system I actually still use. Easy to write, easy to debug, relatively small—what's the issue? I hear people complain about make incessantly but people rarely have substantial criticism to offer. Is it the syntax? Reliance on the filesystem? Inconsistencies between implementations?
        ajb 2y ago
        As an actual builder it has limitations, such as not having (built in) the ability to know if it can still do an incremental build after changing some build option. That can result in inconsistent builds. The main problem is that you often require more logic than makes sense to write in make, but it kind of has a language built into it so people try to use it. But as a language it's terrible (no scoping, many missing features). So people end up implementing their build logic in a bastard combination of make and shell which is very opaque and difficult to debug. For example, I was recently trying to figure out how the OpenWRT makefiles are doing something, and it was really painful, because with make having no scoping any part of the system could end up affecting the piece you are looking at. There is a lot of dropping into shell to get stuff done, and a lot of the targets are themselves expanded variables, which makes it really opaque. Really a lot of it is not gaining from being written in make, they could do with rewriting large parts in a real language. But it would be a huge job. And that's where a lot of makefile systems end up That's why you get tools like ninja where they decided not to allow any logic at all.
        2y ago
  - hamandcheese 2y ago
    Generally my aim with both Nix and Bazel are that, while they are the source of truth, day-to-day development and debugging occurs using language-native tools. So the only touch point for local development is when you are modifying the dependency graph in some way. It's definitely more work (you need to maintain compatibility with two different build systems), but worth it for exactly these reasons.
  - eru 2y ago
    > The point is that there's often no way way to express "I want side effects" in declarative tools, and the number of side effects that might be useful is vast. Shake (https://shakebuild.com/ https://shakebuild.com/) is pretty good about letting you specify that a specific step produces multiple artifacts. I suspect Nix can do the same? > Some other systems (e.g. bazel/blaze comes to mind) actively try to hide side effects like stdout. Yes, blaze isn't all that great. You can tell, because Google folks check in generated artifacts into their repositories, instead of wrestling with getting blaze to build them.
  - IshKebab 2y ago
    So do you just not use incremental builds at all? That's insane.
    - AlotOfReading 2y ago
      Of course I do, but this isn't a thread about all the things that fit well in the paradigm.
__MatrixMan__ 2y ago
Logs emitted during the build, or test results, or metrics captured during the build (such as how long it took)... these can all themselves be build outputs. I've got one where "deploying" means updating a few version strings and image reverences in a different repo. The "build" clones that repo and makes the changes in the necessary spots and makes a commit. Yes, the side effect I want is that the commit gets pushed--which requires my ssh key which is not a build input--but I sort of prefer doing that bit by hand.
- tucosan 2y ago
  The developer time required to learn and properly use nix makes it unattractive to most teams. The benefits don't outweigh the costs of adoption. Instead of debugging code, the team would have to spend significant time maintaining the build system for the build systems sake. Don't get me wrong, I want something nix-like in my toolbox. I want to love nix. But I wouldn't dare to argue my team to commit to the world of pain that comes with it. There's a good reason that nix didn't see wide adoption in the industry.
  - hamandcheese 2y ago
    In my experience, Nix is very high leverage. My company has ~5 nix gurus, but Nix is invisibly used by hundreds of engineers. Most engineers know we use Nix and that's about it.
    - smilliken 2y ago
      Similar experience for me. In my company adopting nix paid off in weeks with no prior experience. Very happy with it almost 10 years later and at much larger scale. The difference between things working reliability or not is too big to overstate.
  - brabel 2y ago
    I tried using Nix but stopped for two very practical reasons: it's very slow and it's extremely disk heavy. Install a couple of things and suddenly your nix store weighs at 100 GB.

thfuran 2y ago

>What I want from a build often isn't the artifacts, but the side effects of producing the artifacts like build output or compilation time You frequently build things not to get binaries but to spend time compiling?

AlotOfReading 2y ago
The point is that there's often no way way to express "I want side effects" in declarative tools, and the number of side effects that might be useful is vast. For example, sometimes I profiling the build times to see where I should focus effort. Sometimes I want to see it to quickly check for issues where adding some dependency header causes build times to explode 100% in downstream dependencies during cold builds. Another common occurrence for is trying to debug a platform, toolchain, or standard library issue and the build system either doesn't detect changes in those components or only makes the components readily accessible in an internal cache that's subject to invalidation issues. You'll usually get the wrong artifact or test results in those cases. Some other systems (e.g. bazel/blaze comes to mind) actively try to hide side effects like stdout. In all of these cases, the only way to actually get these side effects is to reach into the tool's internals by blowing away caches/output folders or reading live log files. That's a failure of the build tool.
- MereInterest 2y ago
  I haven’t used it, but it sounds like make’s —-assume-new flag does exactly what you want for the first part. It lets you rebuild everything that would result from a changed file, including all side effects, without needing to first update the file.
  - AlotOfReading 2y ago
    --always-make/-B is more in line, but yeah. Make has grown imperative models within its vast declarative morass.
  - eru 2y ago
    Alas, Make is really, really awful in most other respects.
    - PittleyDunkin 2y ago
      Really? It's the one part of the traditional c build system I actually still use. Easy to write, easy to debug, relatively small—what's the issue? I hear people complain about make incessantly but people rarely have substantial criticism to offer. Is it the syntax? Reliance on the filesystem? Inconsistencies between implementations?
      - ajb 2y ago
        As an actual builder it has limitations, such as not having (built in) the ability to know if it can still do an incremental build after changing some build option. That can result in inconsistent builds. The main problem is that you often require more logic than makes sense to write in make, but it kind of has a language built into it so people try to use it. But as a language it's terrible (no scoping, many missing features). So people end up implementing their build logic in a bastard combination of make and shell which is very opaque and difficult to debug. For example, I was recently trying to figure out how the OpenWRT makefiles are doing something, and it was really painful, because with make having no scoping any part of the system could end up affecting the piece you are looking at. There is a lot of dropping into shell to get stuff done, and a lot of the targets are themselves expanded variables, which makes it really opaque. Really a lot of it is not gaining from being written in make, they could do with rewriting large parts in a real language. But it would be a huge job. And that's where a lot of makefile systems end up That's why you get tools like ninja where they decided not to allow any logic at all.
        2y ago
- hamandcheese 2y ago
  Generally my aim with both Nix and Bazel are that, while they are the source of truth, day-to-day development and debugging occurs using language-native tools. So the only touch point for local development is when you are modifying the dependency graph in some way. It's definitely more work (you need to maintain compatibility with two different build systems), but worth it for exactly these reasons.
- eru 2y ago
  > The point is that there's often no way way to express "I want side effects" in declarative tools, and the number of side effects that might be useful is vast. Shake (https://shakebuild.com/ https://shakebuild.com/) is pretty good about letting you specify that a specific step produces multiple artifacts. I suspect Nix can do the same? > Some other systems (e.g. bazel/blaze comes to mind) actively try to hide side effects like stdout. Yes, blaze isn't all that great. You can tell, because Google folks check in generated artifacts into their repositories, instead of wrestling with getting blaze to build them.
- IshKebab 2y ago
  So do you just not use incremental builds at all? That's insane.
  - AlotOfReading 2y ago
    Of course I do, but this isn't a thread about all the things that fit well in the paradigm.

__MatrixMan__ 2y ago

Logs emitted during the build, or test results, or metrics captured during the build (such as how long it took)... these can all themselves be build outputs. I've got one where "deploying" means updating a few version strings and image reverences in a different repo. The "build" clones that repo and makes the changes in the necessary spots and makes a commit. Yes, the side effect I want is that the commit gets pushed--which requires my ssh key which is not a build input--but I sort of prefer doing that bit by hand.

tucosan 2y ago
The developer time required to learn and properly use nix makes it unattractive to most teams. The benefits don't outweigh the costs of adoption. Instead of debugging code, the team would have to spend significant time maintaining the build system for the build systems sake. Don't get me wrong, I want something nix-like in my toolbox. I want to love nix. But I wouldn't dare to argue my team to commit to the world of pain that comes with it. There's a good reason that nix didn't see wide adoption in the industry.
- hamandcheese 2y ago
  In my experience, Nix is very high leverage. My company has ~5 nix gurus, but Nix is invisibly used by hundreds of engineers. Most engineers know we use Nix and that's about it.
  - smilliken 2y ago
    Similar experience for me. In my company adopting nix paid off in weeks with no prior experience. Very happy with it almost 10 years later and at much larger scale. The difference between things working reliability or not is too big to overstate.
- brabel 2y ago
  I tried using Nix but stopped for two very practical reasons: it's very slow and it's extremely disk heavy. Install a couple of things and suddenly your nix store weighs at 100 GB.