5 ms·
I think it's fair. It is, by far, the biggest hurdle to adoption and contributions. I'm a SWE and I don't grok it yet. Granted, I haven't spent a ton of time
by eximius 5y ago
I think it's fair. It is, by far, the biggest hurdle to adoption and contributions.
I'm a SWE and I don't grok it yet.
Granted, I haven't spent a ton of time on it. But if you have to spend a ton of time on it, it has in some sense failed.
It's harder to learn than literally any other language I can think of that isn't designed specifically to be esoteric. Most languages, after you have picked up a few, you can just glance at and you've got the basics. Nix is its own beast entirely.
Edit: I do acknowledge that there is some difficult to manage inherent complexity. And, like many others, I love what Nix is trying to be. But I do think improving the language would be a big step.
- jml7c5 5y agoIn my experience, the biggest problems for learning Nix (the language) are the lack of type annotations and the tendency to separate function calls from function arguments. The first time you look in `my-package.nix` you find... a dict of function arguments? I think? What the heck? What function takes these arguments? What function arguments are valid? So you end up grepping the whole source tree for `"./my-package.nix"` just to see what functions are using it, and you find this construct: someFunction ./my-package.nix Which in other languages would be the slightly bizarre some_function( eval_file( "./my-package.foolang" ) ) So you're pretty sure these are arguments to someFunction, but it's weird that the call to `someFunction` wasn't in the same file, because it makes it hard to know what's going on. All of this this wouldn't be so unclear if the syntax wasn't visually similar yet semantically different from most languages. The map syntax in particular looks exactly like a block in curly brace imperative languages: { foo = "blah"; bar = foo + "blahblah"; } ---- Fortunately, there's work to separate Nix (the tool) from Nix (the language), so that any configuration language can be used to produce derivations. Nickel has been one of the drivers of this push: https://discourse.nixos.org/t/nickel-the-nix-language-spin-off/9592 https://discourse.nixos.org/t/nickel-the-nix-language-spin-o... https://github.com/tweag/nickel/issues/93 https://github.com/tweag/nickel/issues/93
- ris 5y ago> I'm a SWE and I don't grok it yet. I think the biggest difficulty most people have is that it's a pure functional language, and that is quite foreign to a lot of people, even many SWEs. It's something that's not going to change though because it's a fundamental part of why Nix works so well.
- JoelMcCracken 5y agoI mean, I am very used to pure functional programming and I still find Nix quite challenging. For a lot of reasons. The abstractions are all weird, there are so many pieces that are confusingly put together, etc. Lots of stuff. Even the PL itself is really weird and unfamiliar. And not super well documented. I remember spending a while not too long ago trying to figure out how to interpolate a string. And then you have goofy stuff like with, etc.
- kokada 5y agoExactly. Before learning Nix I used Elixir and Clojure, so I was pretty much at home using a functional language (even if Clojure/Elixir are not exactly pure functional, but they come close with their immutable data structures). The other thing that trips some people is that Nix has lazy evaluation. Even Elixir or Clojure uses eager evaluation, so this concept is even more uncommon the functional programming. However, this concept bite me just a few times, so it is not like you have frequent issues with it.
- eximius 5y agoHaskell is easier to pick up than Nix.