[dnr]

> 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]

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]

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.