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.
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).
> What might throw people off is that it is functional
None of the languages you list are functional, so that could still explain it.
I'm still sort of confused why it needed its own DSL and couldn't have just reused an existing language.
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.
- 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.
The Nix expression language is in essence just JSON with functions comprising of the following building blocks:
* Primitive values (strings, numbers, paths, booleans, null)
* Lists and sets
* Variables
* Functions
* Conditionals
* Assertions
* Arithmetic operators
And that's basically it. All of this is succinctly explained in the official documentation[1].
[1]: https://nixos.org/manual/nix/stable/#ch-expression-language
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.
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.
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.
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.
Edit: actually looking at contributions Yann Hamdaoui seems like the main contributor, but I saw Eelco contributing to it.
I think what people actually mean is that Nixpkgs is confusing, because that has a ton of weird utility/helper functions that you just need to know, esp. when it comes to what argument they take (which being dynamic doesn't help with at all) and Nixpkgs functions have historically had bad documentation.
Strongly disagree. The Nix custom language is just basically JSON + lambda functions. Way easier to deal with and understand then the mess of the Scheme ecosystem(s).