5 ms·

I've tried many times. I read the entire manual. I would love to use Nix. But it's too complex. I guess that's the result of them trying to do everything an O

I've tried many times. I read the entire manual. I would love to use Nix. But it's too complex. I guess that's the result of them trying to do everything an OS does using their new arcane Nix language. I don't know how else this could be accomplished though -- but I hope there is another way. I find it weird often I would find files written in the Nix language in minified/unreadable way fashion in parts of the system. It's a sympton of the complexity of everything that for every weird error that I would find I would search the internet and not find a person with the same problem. It's always something slightly different and then the solutions proposed to that person would made no sense to me at all or they would introduce much more complexity.

k__ 6y ago
I don't think the problem is really complexity. It's just the config language. If you come from a Haskell background its nice, otherwise it's "arcane". Try Guix-SD.
- sigzero 6y ago
  I am pretty sure moving from a DSL based on Haskell to Guile isn't a "step up" for most people.
- fiatjaf 6y ago
  The language doesn't matter. It is actually very simple and nice (I read the manual, did the tutorial). You still have to learn all the thousands of obscure schemas each thing expects and supports. Could be written in JavaScript and you would still not know what is going on and would have to waste months in documentation and support forums. Or maybe the documentation is just very incomplete, I don't know.
- patrec 6y ago
  Actually, unlike most DSLs, the nix language itself is pretty great and can be learned in an afternoon by any competent programmer, no Haskell background needed. The problem absolutely is complexity, and there is a lot of stuff you need to grok to be able to use nix productively in anger and sadly that includes a lot of stuff that really ought to be much more straightforward. Also, IMO you don't do anyone a favor by recommending they try Guix-SD over NixOS unless you also make it pretty clear that Guix is quite fringe even compared to Nix. For example Nix can and is being used for Real Work by well known companies. It as a steep learning curve but also, for certain tasks, an enormous payoff that justifies this effort.
  - k__ 6y ago
    Sure. I was just talking from my perspective. And I found Guile much easier than Nix. The complexity difference of NixOS compared to, let's say, Arch felt like Git to Subversion. It makes totally sense to me that a fundamentally different model of package management would require some rethinking, but it didn't make sense to me to create such a strange language for it (like Guix has proven).
    - patrec 6y ago
      I think if you're setting up a personal machine, your reasoning completely applies and a fairly superficial difference, like scheme being a more familiar language can indeed make a big difference. But I think NixOS or Guix-SD vs Ubuntu or Arch as your daily driver is mostly window dressing, you will not unlock significant productivity benefits by this choice alone unless you leverage it for setting up e.g. a unified dev/ci/prod setup with reproducible builds. At least streamlining artefact creation is where the real productivity benefits tend to come from in my experience. However, from my own production experience with nix I find that language related overheads and frictions are just completely in the noise compared to grokking e.g. the many different flavors of overriding stuff or working out good workflows for pinning and bumping nixpkgs and individual dependencies, providing suitable overlays and integrating native language tooling (poetry, yarn, cargo etc.) with nix etc. etc. Now the language itself does have some psychological effect on wider adoption, but effectively scheme is equally obscure to almost any target audience and, IMO, an inferior design for this problem space, that presents a larger rather than smaller hurdle for most people. I guess the debugging experience at least must be better? Don't get me wrong, I'd prefer 99% of shitty DSLs (cmake, make, pom, jinja, moustache, chef and so on and so forth) had just used even a mediocre internal lisp/scheme DSL. However, I'd say Nix is a bit of an outlier: it's IMO a remarkably elegant design that really pulls its own weight. Most of my complaints (poor debugging experience and error messages) are quality of implemenation rather than language design as such – I am not quite sure to what extent this applies to lack of static typing. In any case one of the main usability defects of nix is shared by guix: 90% of cases should be declarative toml or similar, not some weirdo turing complete language. It's great to have a powerful language for the bits that actually need it, but a lot off stuff really shouldn't. In particular mixing metadata (description, hashes, version numbers, urls etc.) with build descriptions is just a dumb and painful way to do things and completely screws up tooling. There are tools to help with that (e.g. niv), but this should just be fixed at the source.

k__ 6y ago

I don't think the problem is really complexity. It's just the config language. If you come from a Haskell background its nice, otherwise it's "arcane". Try Guix-SD.

sigzero 6y ago
I am pretty sure moving from a DSL based on Haskell to Guile isn't a "step up" for most people.
fiatjaf 6y ago
The language doesn't matter. It is actually very simple and nice (I read the manual, did the tutorial). You still have to learn all the thousands of obscure schemas each thing expects and supports. Could be written in JavaScript and you would still not know what is going on and would have to waste months in documentation and support forums. Or maybe the documentation is just very incomplete, I don't know.
patrec 6y ago
Actually, unlike most DSLs, the nix language itself is pretty great and can be learned in an afternoon by any competent programmer, no Haskell background needed. The problem absolutely is complexity, and there is a lot of stuff you need to grok to be able to use nix productively in anger and sadly that includes a lot of stuff that really ought to be much more straightforward. Also, IMO you don't do anyone a favor by recommending they try Guix-SD over NixOS unless you also make it pretty clear that Guix is quite fringe even compared to Nix. For example Nix can and is being used for Real Work by well known companies. It as a steep learning curve but also, for certain tasks, an enormous payoff that justifies this effort.
- k__ 6y ago
  Sure. I was just talking from my perspective. And I found Guile much easier than Nix. The complexity difference of NixOS compared to, let's say, Arch felt like Git to Subversion. It makes totally sense to me that a fundamentally different model of package management would require some rethinking, but it didn't make sense to me to create such a strange language for it (like Guix has proven).
  - patrec 6y ago
    I think if you're setting up a personal machine, your reasoning completely applies and a fairly superficial difference, like scheme being a more familiar language can indeed make a big difference. But I think NixOS or Guix-SD vs Ubuntu or Arch as your daily driver is mostly window dressing, you will not unlock significant productivity benefits by this choice alone unless you leverage it for setting up e.g. a unified dev/ci/prod setup with reproducible builds. At least streamlining artefact creation is where the real productivity benefits tend to come from in my experience. However, from my own production experience with nix I find that language related overheads and frictions are just completely in the noise compared to grokking e.g. the many different flavors of overriding stuff or working out good workflows for pinning and bumping nixpkgs and individual dependencies, providing suitable overlays and integrating native language tooling (poetry, yarn, cargo etc.) with nix etc. etc. Now the language itself does have some psychological effect on wider adoption, but effectively scheme is equally obscure to almost any target audience and, IMO, an inferior design for this problem space, that presents a larger rather than smaller hurdle for most people. I guess the debugging experience at least must be better? Don't get me wrong, I'd prefer 99% of shitty DSLs (cmake, make, pom, jinja, moustache, chef and so on and so forth) had just used even a mediocre internal lisp/scheme DSL. However, I'd say Nix is a bit of an outlier: it's IMO a remarkably elegant design that really pulls its own weight. Most of my complaints (poor debugging experience and error messages) are quality of implemenation rather than language design as such – I am not quite sure to what extent this applies to lack of static typing. In any case one of the main usability defects of nix is shared by guix: 90% of cases should be declarative toml or similar, not some weirdo turing complete language. It's great to have a powerful language for the bits that actually need it, but a lot off stuff really shouldn't. In particular mixing metadata (description, hashes, version numbers, urls etc.) with build descriptions is just a dumb and painful way to do things and completely screws up tooling. There are tools to help with that (e.g. niv), but this should just be fixed at the source.