4 ms·

It's a higher level issue, declarative vs. programmatic environment control. It isn't that sysadmins don't understand programming, functional programming, etc.

It's a higher level issue, declarative vs. programmatic environment control. It isn't that sysadmins don't understand programming, functional programming, etc.--everyone is devops these days. It's that in the world of system administration we've gone through many waves and trends with significant backlash against complete programmatic definition of environments. In the old days you'd exec a pile of shell scripts to go out and put your servers into the state you wanted. It was brittle, painful to understand, etc. Then things evolved into declarative definition of environments with tools like ansible. Now you just define the state of the world you want and ansible or other tools do the work to get the world into that state. This has evolved even further into declarative definition of entire distributed systems with kubernetes--you write out a pile of YAML that defines the state you want and kubetl and k8s controllers take care of making it happen. So there are definitely people that understand the value of functional programming, but don't want it to define their environments. I don't want to have to grok someone's 'clever' solutions to figure out that ultimately they just want package x, y, z and software foo installed. I just want to list what I want and let the tooling make it happen.

dnr 5y ago
> I just want to list what I want and let the tooling make it happen. That's just what Nix does? It's very much more declarative than any system I've seen. Yes, k8s turns your declarative manifest into running processes, but how was the image built? There's a huge gap there: you refer to container images by name, not by a description of the software you want them to contain, and then hope that some other process has built the image correctly. Nix can close that gap and take declarative all the way from the service manifest down to the git commit of the compiler used to build your binary.
- rgoulter 5y ago
  The comment you're replying to describes concerns about maintenance burden from the programmatic nature of Nix. I think "declared in YAML, pointing to a Docker image", and "declared in Nix, pointing to some more Nix elsewhere in the codebase" is relatively moot to this point. (If you wrote the image, you'll know what it's expected to do; if you don't know the Nix you're pointing to, it's as opaque as a Docker image). Configuring with a program vs using a plain structured file have different trade-offs.
  - dnr 5y ago
    Does anyone write k8s manifests in raw yaml? They're so complicated that they're generated using some templating language (helm or kustomize or whatever is popular these days, I'm a little out of the loop). So you still have something programmatic. Think of Nix as just a better and more principled templating language. (I mean, look at NixOS configs: they're much closer to "plain structured files" than "programs".) The promise that I see (I haven't seen this fully realized but it should be possible) is that instead of yaml plus some ad-hoc templating language plus dockerfile plus makefile, everything is in a single language top to bottom.
    - rgoulter 5y ago
      I think it's better to put in terms of trade-offs, rather than "this is better than that". https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html https://mikehadlow.blogspot.com/2012/05/configuration-comple... (I use NixOS btw).
    - rezonant 5y ago
      Helm charts are basically just collections of k8s yamls, it doesn't serve to simplify them, only to make them parameterized

dnr 5y ago

> I just want to list what I want and let the tooling make it happen. That's just what Nix does? It's very much more declarative than any system I've seen. Yes, k8s turns your declarative manifest into running processes, but how was the image built? There's a huge gap there: you refer to container images by name, not by a description of the software you want them to contain, and then hope that some other process has built the image correctly. Nix can close that gap and take declarative all the way from the service manifest down to the git commit of the compiler used to build your binary.

rgoulter 5y ago
The comment you're replying to describes concerns about maintenance burden from the programmatic nature of Nix. I think "declared in YAML, pointing to a Docker image", and "declared in Nix, pointing to some more Nix elsewhere in the codebase" is relatively moot to this point. (If you wrote the image, you'll know what it's expected to do; if you don't know the Nix you're pointing to, it's as opaque as a Docker image). Configuring with a program vs using a plain structured file have different trade-offs.
- dnr 5y ago
  Does anyone write k8s manifests in raw yaml? They're so complicated that they're generated using some templating language (helm or kustomize or whatever is popular these days, I'm a little out of the loop). So you still have something programmatic. Think of Nix as just a better and more principled templating language. (I mean, look at NixOS configs: they're much closer to "plain structured files" than "programs".) The promise that I see (I haven't seen this fully realized but it should be possible) is that instead of yaml plus some ad-hoc templating language plus dockerfile plus makefile, everything is in a single language top to bottom.
  - rgoulter 5y ago
    I think it's better to put in terms of trade-offs, rather than "this is better than that". https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html https://mikehadlow.blogspot.com/2012/05/configuration-comple... (I use NixOS btw).
  - rezonant 5y ago
    Helm charts are basically just collections of k8s yamls, it doesn't serve to simplify them, only to make them parameterized