As a longtime Nix user with very little prior FP experience (1/4 of one course in college doing a few exercises in Haskell), I think the Nix language is actuall

As a longtime Nix user with very little prior FP experience (1/4 of one course in college doing a few exercises in Haskell), I think the Nix language is actually very well-suited to task. The biggest difficulty comes from the fact that it is a dynamic, weakly-typed language, which can lead error messages in configuration to point you toward library code rather than your config file. This is a pitfall shared by many of the languages that are commonly suggested as replacements or alternatives. There's been work to solve this by adding gradual typing (like in Typescript) to Nix, whose most promising iteration atm is (imo) a Nix-like language called Nickel, which is almost ready for preview by the community. The other, more minor, issue is tooling, which is being addressed by emerging LSP work for Nix. (Scripting is done in Nixpkgs, mostly via Bash.) The beauty of Nixlang, imo, is that for simple use cases it really feels like a dead simple configuration language, which is only possible with a declarative language. The functional character and Nix's laziness were important in the early design of Nix. The latter may still give Nix some nice performance characteristics. But since the initial Nix design, Nix has become eager in some places, and Guix is implemented as a lazy DSL embedded in an eager language, so I guess we could implement something like Nix on top of an eager scripting language. Imperative scripting languages might not be as well suited for the kinds of overrides that Nixpkgs and NixOS use, afaict. But imo aside from its novelty, the Nix language is nice to use because it's really simple and totally declarative, which is what you expect from a configuration language.