[OhSoHumble]

I'm hesitant to write this as I don't know if you'll see it but I feel like what I have to say is different to the opinions that have been voiced so far. I will only answer for point number one.

I personally feel that Nix documentation and community blog posts sits on a gradient of theological meanderings about functional purity to actual praxis.

For one, I'm a systems engineer. What drew me to Nix was that I wanted a next-gen Ansible. A piece of software that can be used to reproduce a hosts OS state in an immutable way. For now, my homelab and laptop is all NixOS driven. I use deploy-rs and flakes to configure hosts. I can code but am not really a software engineer by trade. This is where I'm coming from.

Within the context of my established skills, Nix's documentation is awful. There were/are actions I want to accomplish that sit outside of the paradigm of Nix and when I try to accomplish those actions I feel lost.

For example, my main homelab machine has a Nomad server installed. The default Nomad package from Nix packages just installs the binary. So I needed to handle creating its data directory, its configuration, and laying down a systemd unit file. Where I got stuck was creating the data directory. I could accomplish the systemd configuration and the configuration file easily enough but I don't know how to create a directory outside of a derivation. I also don't know if a derivation is even needed.

But I also don't really know how to fit a derivation in my current flake setup so that it's processed when I change host state. I ended up solving the problem by having systemd manage a StateDirectory and creating the unit file/Nomad conf in configuration.nix for the machine. I also don't known if a derivation would even be what's needed. Do I use an overlay to extend the Nomad package? Can I ad-hoc create directories and then shove that into a module?

My point being is that system administrators, network engineers, release engineers, etc are all different types of engineers that would be interested in Nix... but they are NOT functional programming enthusiasts. I think Nix gets attention from a lot of people who are comfortable with Linux, package management, build processes, and configuration management systems like Ansible. But there is no clear runway for those types of engineers. Hell, NixOps seems to be an abandoned repo that has no documentation whatsoever for it's 2.0 release and there are dozen different projects for remote deployment to hosts.

If I took a sysadmin and told them "please codify OS state using Ansible" then they're likely to come back with a solution that could satisfy a technical need within an organization. If I took that same sysadmin and told them to use Nix to solve the same problem then they're likely to get lost for weeks.

[tomberek]

I'm reading these.

It seems this is where a better description of what NixOS (and it's module system) is. My suspicion is that by starting with NixOS it is harder to be introduced to the simpler concepts. It is best to think of the NixOS modules as a domain-specific-language on top of Nixpkgs which is itself a large set of conventions on top of the fairly simple Nix language. I think people should be introduced from the bottom up.

> having systemd manage a StateDirectory and creating the unit file/Nomad conf in configuration.nix for the machine

Seems like you did get what you needed working; my best advice to understand that the key abstraction being created is the activation script. Perhaps we never clearly describe all of its moving parts and how it works?

> ... but they are NOT functional programming enthusiasts

I believe the key is for the Nix community messaging/marketing to focus less on the theoretical elegance and more on the practical benefits.