Other languages were deemed too big, especially in 2003 when Nix was started. Nix is a strict diet. Perhaps something else could be used, but I can assure you Nixpkgs would be a completely failed experiment drowning in its own complexity if there were side effects.
Also, I don't understand how people can say the semantics is fine but the syntax is challenging. Syntax is entirely superficial. And if you are having trouble reading the syntax, how can you be sure the semantics isn't challenging?
There are a lot of funny fixed points used in Nixpkgs and that is challenging to think about.
The Nix properties fit ideally with the domain it tries to solve:
- functional with no side effects (for the same imput you always supposed to get the exact same output); derivation is function of its inputs (e.g. source code, dependencies, compiler flags, architecture and so on) if none of them changes you're expecting to get the same file. Introducing side effects would remove this guarantee, and introduce bugs.
- lazily evaluated - you can specify multiple things but Nix will process only the ones that are referenced, this makes weird experience that the code isn't executed from top to bottom (as most people would expect)
Those two things essentially makes the derivation declarative. You specify what derivation you want and what it needs (like dependencies) you can also use the language to transform the inputs to the way you like and still preserving the guarantee that if one dependency changes the project needs to be rebuilt.
> What might throw people off is that it is functional
None of the languages you list are functional, so that could still explain it.