Nix has supported JSON derivations for years, e.g. using commands like `nix derivation show` (I have Emacs configured to run that on any `/nix/store/foo.drv` file I open). It still serialises to ATerm on disk, to avoid breaking existing hashes; which I think is reasonable.

If you mean the programming language used to generate those derivations, then I have no idea what that would even look like; some horrific bastardisation like https://github.com/gliese1337/json-lisp ?

PS: I I found that json-lisp project with a quick search for a LISP-like language that used JSON instead of s-expressions. I like how its README says "Due to the excessive cumbersomeness of writing code in JSON, it is expected that most applications of this library will use it for interpreting auto-generated code of some sort, or API calls, or config files.". If we used that to generate Nix derivations, then we'd want a third* language to generate the json-lisp that generates the derivations ;)

What? No! Nix-the-language certainly isn't great, but there's nothing better about JSON/YAML in this role. The whole point of Nix is that it's a programming language that allows you to build abstractions in the language itself, not just pure data.

I rarely downvote on HN, but when I do, it must be a comment promoting JSON over any other configuration language (sorry)

Nix isn't even that arcane. Its documentation simply sucks. Once you grasp the idea, it feels almost great