> what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing.
I think I agree with this.
> the difficulty people have with it is that it’s functional, not that it’s nix.
No I don't think that's the problem people have with it. Speaking for myself the thing that's hard about Nix is first and foremost the bad error messages and secondly the complexity of idioms used in nixpkgs. If you stray just a little bit from the happy path, you're liable to get a ton of very arcane problems, and the error message often has nothing to do with the actual problem because a lot of the idioms used in nixpkgs end up doing clever things with Nix that work well when everything lines up just right, but blow up when just a little bit is wrong.
The functional parts of Nix can be obstacles for someone new to functional programming, but when something goes wrong the developer has a clear sense of what is wrong ("ugh why is this immutable?!") even if it's not clear how to fix it. The sheer complexity of nixpkgs though can cause breakages in ways that don't make it clear at all what went wrong.
There are a variety of ways that this could be fixed either in concert with changes to the language itself, or whole-scale changes to the interpreter/compiler.
For me it's a total lack of any description of the nix language. I just have no idea what I'm looking at, and nowhere (last time I looked, which I admit was some time ago) explained what tokens make up the language. Some showed that parts of the syntax were optional, but not what they meant.
Occasionally I'd find a guide that describes in English what a given example file is doing, and it kind-of made sense, but wasn't clear how it mapped to the file shown. There was a lot of magic going on with no explanation how it was getting there, so I could only assume there were semantics tied to some of the syntax that the writer assumed you'd eventually figure out... But they were just abstract enough that it didn't make sense in a way I could duplicate.
The problem is not the language but the “standard library” used by it, which is quite ad hoc and organically built.
The language may not be the most intuitive at parts, but I feel that it is not the actual problem people have - I think what trips up people (me included) is that one pretty much grep for a similar package to be able to start doing the work. Why does a python derivation require this function instead of the generic one, what are the package names, etc. Some stricter structure would be welcome, in my opinion.
> For me it's a total lack of any description of the nix language. I just have no idea what I'm looking at, and nowhere (last time I looked, which I admit was some time ago) explained what tokens make up the language. Some showed that parts of the syntax were optional, but not what they meant.
It's not perfect and I raised some issues about fragments being written from the perspective of someone who knows the system - but it's definitely good enough for learning the language.
I don't think the Nix language requires understanding of functional programming. Overall, it's not so different from JSON. What is different is that it provides a few programming language constructs on top like variables, functions, and conditionals. This enables developers using the Nix language to properly abstract complex configurations in a comprehensible way, thus avoiding the pitfalls of writing JSON and YAML by hand.
you’re right. I guess I should qualify that with: what makes the language more difficult to approach as a newcomer.
once you’re in there, there’s a ton of warts, of course. I just hear complaints about the syntax so much that it really seems like people are more caught up learning functional programming than Nix. which makes sense, since most people who would need Nix spend their time writing Bash and Python
I think the problem is that the bad error messages make it unclear whether something is a syntax issue or a nixpkgs issue (this is somewhat worse with the dynamic nature of Nix, although I personally don't actually think Nix really needs static typing all that much, but that would be one viable way of fixing this).
One reason is that Scheme has Emacs modes that connect to a live system for precise jump-to-definition, etc. This works with Guix and is extremely convenient. Scheme's metaprogramming also enables Guix's beautiful system of code staging, G-expressions.
> One reason is that Scheme has Emacs modes that connect to a live system for precise jump-to-definition, etc. This works with Guix and is extremely convenient.
Those are all valuable things, but I don't think that would actually be hard to implement for the Nix language either. Just no one bothered
> Scheme's metaprogramming also enables Guix's beautiful system of code staging, G-expressions.
Yes not pasting together strings for bash would be nice, but with all due respect to scheme's metaprogramming, which I do indeed highly respect, I view this as fairly orthogonal.
From a quick glance, g-exps don't have much binding structure? That means hygiene and other things are not as useful, and just doing
["see" "I" "can" "sexp" "too"]
in the Nix expression language isn't actually so bad.
With G-expressions you can splice in computed store values, e.g. the computed output location of a package. I recommend the paper[1] explaining why they exist and what alternatives they replace.
It's not purely a language thing per se, i.e. there are ways the language could change minimally but error messages could have a huge leap in improvement. However, certain idioms in the standard library might need to change, and certainly changing the language at the same time can improve the error messages even more.
I have only a little experience with Guix (replacing Nix with Scheme), so I'm not very confident in this, but the shallow impression I have is that Guix's error messages are not much better.
I think I agree with this.
> the difficulty people have with it is that it’s functional, not that it’s nix.
No I don't think that's the problem people have with it. Speaking for myself the thing that's hard about Nix is first and foremost the bad error messages and secondly the complexity of idioms used in nixpkgs. If you stray just a little bit from the happy path, you're liable to get a ton of very arcane problems, and the error message often has nothing to do with the actual problem because a lot of the idioms used in nixpkgs end up doing clever things with Nix that work well when everything lines up just right, but blow up when just a little bit is wrong.
The functional parts of Nix can be obstacles for someone new to functional programming, but when something goes wrong the developer has a clear sense of what is wrong ("ugh why is this immutable?!") even if it's not clear how to fix it. The sheer complexity of nixpkgs though can cause breakages in ways that don't make it clear at all what went wrong.
There are a variety of ways that this could be fixed either in concert with changes to the language itself, or whole-scale changes to the interpreter/compiler.