There's a lot of bashing of Nix language, but frankly I don't think Nix really is a problem. The language is fairly simple.
What might throw people off is that it is functional (which applies to Scheme/Guile as well).
I think the biggest problem of Nix is that the area it covers is so vast and because of that it is suffering from not having enough people working on it, which also affects the quality of the documentation. I don't know where Guix is in this area.
Regarding the language being dynamic, I recently found that there's work on making a typed language: https://github.com/tweag/nickel
When I got into Nix and Guix I tried both and I leaned towards Guix because "it's scheme" but ended up sticking to Nix because of maturity, Darwing support and it being way more performant.
In the end I realized that I actually prefer Nix as a language. I like that it's a very simple and limited language, with, for example, no way of performing side-effects. It is tailored towards it's purpose and, while not perfect, it does the job well.
As other point out, Nixpkgs and the Nix toolchain in general just uses very weird names for everything, plus the docs. That's the difficult bit. It's slightly improving over time.
I don't see that Nix would be more widespread if it used (say) JavaScript instead of Nix-lang for its expressions.
When you face problems, I'm sure it's more likely that you won't know how to do it with NixOS/Nixpkgs, rather than you'll know exactly what needs to be done but don't know how to express it in Nix-lang.
I program in a half-dozen common languages and read ten more, and have been doing so for decades and the Nix DSL still confuses me. I would not say it is fairly simple.
Perhaps this will change with more doc reading, but it is anything but intuitive (coming from a C, Perl, Java, JS, PHP, Python, Go, et c background).
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.
Those are all the same language, that are different dialects of each other. Conceptually they are all very similar, and once you know one well, you understand %90 of the other ones. Java, C & Golang are the only ones that are bit different with static typing, manual memory management (C) and language level concurrency.
Nix DSL, Haskell, OCaml, declarative UI libraries, Rx and other declarative paradigms are fairly different and do require a bit of new learning. They go way beyond functional programing basics like map and filter.
I can't disagree more. All of the languages you have listed are well known for having complex semantics. This is totally expected of any general purpose programming language, of course. But the Nix expression language, though Turing-complete, isn't meant to be a general purpose programming language. It's a configuration DSL for defining packages. As such, it has a much smaller feature set with fewer confusing semantics.
The Nix expression language is in essence just JSON with functions comprising of the following building blocks:
Bazel has starlark, which is reduced python, which I've found in practice fairly easy to understand. Do you think the nix DSL could of been replaced with bazel's model of doing things and would meet the same functionality? I'm not very familiar with nix.
As a nix-lang fan, I've been using dhall as a nix-like build system configuration language when I need to work outside of the nix ecosystem. I love its use of static typing, but it's not without its rough edges. Defining recursive types is not simple and writing configs which need to mix rigidly-typed domain knowledge with arbitrary loose json data can be very tricky.
It looks nickel's authors have these use cases in mind. I'm excited to keep an eye on this project.
The Nickel author is the Nix author or at least one of contributors (Eelco Dolstra) so as long as the project is successful it will likely be introduced back to Nix.
Edit: actually looking at contributions Yann Hamdaoui seems like the main contributor, but I saw Eelco contributing to it.
Cuelang may be nice for some domains, but it's not a sensible replacement for the Nix language. If it was ever replaced by Cuelang, fundamental Nix abstractions would go missing or become awkward to deal with due to lack of expressiveness.
What might throw people off is that it is functional (which applies to Scheme/Guile as well).
I think the biggest problem of Nix is that the area it covers is so vast and because of that it is suffering from not having enough people working on it, which also affects the quality of the documentation. I don't know where Guix is in this area.
Regarding the language being dynamic, I recently found that there's work on making a typed language: https://github.com/tweag/nickel
Perhaps it can solve this problem.