I wouldn't say they are very similar. Nix is a fairly barebone functional language, so it does embed fairly straightforwardly into other functional languages (including Nickel, but it's true for Haskell, OCaml, Dhall, Jsonnet, Scala, etc. as well - forgetting about Nix-specific builtins, as long as you have higher-order functions, records and arrays, you have the Nix core).
However, Nickel adds pattern matching and destructuring, reverse application, types, contracts and merging, which I think does lead to a quite different experience in practice. It's a bit like saying that C is similar to Rust (ok, so the analogy doesn't work as well for Rust as most C would be unsafe on non-idiomatic Rust) or C++: in some sense, yes, but developing in those languages is very very different.
In Nix, I've found that the biggest problem is not the language but the lack of easy introspection. Which keys are present in the struct I'm looking at? What are all the symbols in point X? Etc. It felt like an "ok to read but hard to write" language.
I think it's resolved by a proper IDE and runtime-inspection of some kind.
1. If you like Nix, you'll probably like Nickel, too.
2. If you use Nix enough that there are enough specific things you hate about it to comprise a wishlist, you might be extra excited about Nickel for checking some of those boxes.
3. If you looked at Nix code for 5 minutes and instantly bounced off it because it seemed alien and unpleasant, Nickel might give you similar feelings.
I think (3) often resolves itself with experience, so it's potentially worth coming back to Nix or Nickel in a more patient and curious mode, if you've had that reaction.
Comments
If you don't like the Nix language, you're unlikely to like Nickel - they're very similar.
I wouldn't say they are very similar. Nix is a fairly barebone functional language, so it does embed fairly straightforwardly into other functional languages (including Nickel, but it's true for Haskell, OCaml, Dhall, Jsonnet, Scala, etc. as well - forgetting about Nix-specific builtins, as long as you have higher-order functions, records and arrays, you have the Nix core).
However, Nickel adds pattern matching and destructuring, reverse application, types, contracts and merging, which I think does lead to a quite different experience in practice. It's a bit like saying that C is similar to Rust (ok, so the analogy doesn't work as well for Rust as most C would be unsafe on non-idiomatic Rust) or C++: in some sense, yes, but developing in those languages is very very different.
In Nix, I've found that the biggest problem is not the language but the lack of easy introspection. Which keys are present in the struct I'm looking at? What are all the symbols in point X? Etc. It felt like an "ok to read but hard to write" language.
I think it's resolved by a proper IDE and runtime-inspection of some kind.
I would weaken and expand this a bit.
1. If you like Nix, you'll probably like Nickel, too.
2. If you use Nix enough that there are enough specific things you hate about it to comprise a wishlist, you might be extra excited about Nickel for checking some of those boxes.
3. If you looked at Nix code for 5 minutes and instantly bounced off it because it seemed alien and unpleasant, Nickel might give you similar feelings.
I think (3) often resolves itself with experience, so it's potentially worth coming back to Nix or Nickel in a more patient and curious mode, if you've had that reaction.