10 ms·

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated,

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold less and the learning curve doesn't require half a decade. Got stuff to do!

gonehome 3y ago
This matches my experience with it so far. Extremely complicated and hard to understand, projects that use it have builds fail anyway except now with very hard to debug errors.
- lillecarl 3y ago
  When a nix build fails it'll fail with errors from the build system the package uses. The upside is that your failure is now reproducible.
  - ParetoOptimal 3y ago
    Good point. I'm much more likely to help others because I know I can get to the exact state they are in and reproduce their issue with a simple `nix build`.
- SuperSandro2000 3y ago
  > Extremely complicated and hard to understand That is absolutely not true. If you start to get the hang of it and follow the way things are supposed to be done then things get easier over time. You need to invest upfront more time into your configuration but on the long run it pays off and saves you from an entire error class. > projects that use it have builds fail anyway The point of Nix/NixOS is not to have no failing builds but that those are reproducible and deterministic as much as possible and that those failures are noticed early and before the point of no return. A system build is supposed to fail early and not mid way through a major update and prompting you to merge some config under /etc by hand.
  - thumbuddy 3y ago
    I've never seen it actually pay off in industry. I've seen it be used as good job security while other devs just wrote docker files and got things done.
    - skulk 3y ago
      Then you're not paying enough attention. There are plenty of companies using nix to distribute a reproducible environment (if you don't believe me, why not go search GitHub for "flake.nix" and see how many "industry" repos you find). I think it would be more productive for you to sit down and give it a fair chance than posting little rebukes all over this thread.
      - thumbuddy 3y ago
        I gave it a fair chance and it was a deciding factor in why I left a company believe it or not. Only one person could maintain and fix deployments. Not from lack of trying from seasoned experts and no new comers. It was the worst user experience I have probably ever encountered. Meanwhile I was able to pick up terraform and docker in a matter of days...
    - __MatrixMan__ 3y ago
      As the only guy maintaining the flake.nix in my team's repo, I don't think it's really contributing to my job security. I'm just happy that they don't mind the extra files and commits here and there because I value the ability to contribute from different devices without worrying about which versions of what are installed. Maybe it'll be job security if people start agreeing that downloading binary tools in in CI without a hash check is unacceptable attack surface, but until then it's just this weird thing I'm doing on the side. I do catch a lot of bugs where people are relying on dependencies that they happen to have installed but have not declared. It's the kind of thing that prevents newcomers from being successful out of the gate, or makes taking a local process and putting it in CI difficult, but fixing those is not exactly high visibility.
    - SuperSandro2000 3y ago
lillecarl 3y ago
You don't have to manage your system with NixOS to reap the benefits of Nix. It solves very real problems that very much exist, it might not exist if you're a one-man show deploying WordPress to GoDaddy though. Barrier to entry: 1. Run the nix installer 2. Enable flakes 3. cd project 4. nix run This ensures you run the package with every dependency except the kernel pinned to a hashed version. If dependency hell is not a problem for you, be happy!
- awelkie 3y ago
  Step two is not even necessary if you use zero-to-nix's installer. https://zero-to-nix.com/start/install https://zero-to-nix.com/start/install
  - lillecarl 3y ago
    Yup, I just didn't wanna confuse the already pessimistic person by saying "use the unofficial installer" :)
- thumbuddy 3y ago
  You're omitting the entire thing about learning how to write nix. Which is nightmare fuel even for FP fans.
  - SuperSandro2000 3y ago
    Unless you are attempting advanced things you don't need to know a lot about the language and how the more advanced things work.
  - pxc 3y ago
    Imo the harder part is learning bespoke build processes that you may not own in order to get software that assumes it can perform arbitrary network access or other naughtiness at build time to build successfully in a restricted sandbox. The language is maybe a little strange at first but there's really not much to it.
  - kaba0 3y ago
SuperSandro2000 3y ago
> The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. That's simple: nix is a package manager and the language used by the package manager, NixOS is a Linux distro. > It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. From someone who is working as a DevOps Engineer for some years and managing Linux servers for a few years longer that thought is incredible naive. The problem of undefined and undocumented system state is a fundamental problem I encounter everywhere especially bad with legacy systems. I often do things on them blind and just pray for the best outcome, realising months later that some system was broken by one change I did and no one realised that for months. > I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold less and the learning curve doesn't require half a decade. Got stuff to do! I thought the same first but unwedging Debian once a week on a different system is also not fun and a waste of time and having servers in some undefined state and no one who how the config is supposed to be and why or when it got changed, too. The result in the end is that every system is different and unique and your Ansible playbook to run a common and good thought out task succeeds on 15 VMs and sometimes completely blows up the 16th because no one could have thought that the state of configuration there is so widely different.
- joshSzep 3y ago
  Nix vs not Nix seems like a parallel to Infrastructure As Code (terraform for example) vs Cowboying the AWS Console. Is that a fair comparison?
  - thumbuddy 3y ago
    Not really, unfortunately. In my opinion, Nix is more like using Haskell instead of whatever language your team is using to write software.
    - SuperSandro2000 3y ago
      I got pretty far the first year without really writing much nix code at all.
ParetoOptimal 3y ago
> In my opinion the problem it attempts to solve doesn't really exist. It does, but some people are good at numbing themselves to it. So they block losing a day or half day from lack of reproducibility out of their memory or recall it as "no big deal".
- justinhj 3y ago
  Nobody loses time on Nix issues?
  - thumbuddy 3y ago
    I can say from personal experience I've seen many days devoted exclusively to Nix upkeep and maintenance. That was from junior people to people who had spent half a decade or so deeply in the community and using Nix for their daily driver.
    - pxc 3y ago
      I've never had to do much for Nix itself, but packaging something to build from source can often require quite some effort. Applications that use a pretty unconstrained build/install process upstream may expect to do a lot of things that are not allowed in the Nix build sandbox, like unconstrained network access and or overwriting files in existing packages on the system. To deal with that you really have to dive in, learn how the sausage gets made in the upstream package, make some choices about if/where to compromise, and then spend some time tweaking and debugging. That can be a pain and can definitely take a day or two. I've only had 'maintenance' issues with Nix itself on macOS, where OS upgrades routinely nuke Nix's hooks into the OS or add restrictions that break things. (But they do that to other package managers as well.)
      - ParetoOptimal 3y ago
        You can mitigate this to some extent by approaching it as described here: https://www.haskellforall.com/2022/08/incrementally-package-haskell-program.html https://www.haskellforall.com/2022/08/incrementally-package-... I think Graham Christensen had a blog post along these lines... I'll see if I can find it. Edit: I couldn't find it... but I thought someone made a blog post about gradual adoption of Nix into a codebase.
pmarreck 3y ago
You basically have two choices: you can take the complexity upfront, and in a predictable fashion by learning Nix, or you can deal with the complexity after the fact when you’re dealing with dependency hell and a deadline is looming and your boss and/or client is mad. The Nix language is basically JSON plus syntax sugar plus pure functions. A Nix derivation can be thought of as a super-powered lockfile that includes not just the versions of the dependencies, but also the build instructions and the environment in which to build them. The argument for Nix is basically the same argument as the one for writing pure functions as much as possible, or not doing so. Any amount of experience doing the former will demonstrate that it is superior. Now, Nix may be complex, and some of that may be reducible, but the fundamental idea of treating a build like a pure function is NOT reducible, and is well worth the effort of learning, because it will apply to ANY future pure build and dependency management tool
marcosdumay 3y ago
> In my opinion the problem it attempts to solve doesn't really exist. Almost all of Docker use-cases are for solving that same problem, but badly and with partial completeness. The lack of adoption is really not caused by lack of value.
earthling8118 3y ago
You can continue spending your time messing around with your system then. I learned nix in a short amount of time and it has supercharged my development workflows and reduced the overall complexity. I have too much stuff to get done to not use it.
- preseinger 3y ago
  supercharged!!! how much faster are your development workflows now, versus before? like 100x? how complex were your previous development workflows? what did that complexity manifest as? how has nix made it less complex? i'm excited to learn more
II2II 3y ago
Based upon how I manage my system, Nix appears to be something that I could use productively. The problem isn't so much of them being able to explain what the tool is, but one of them being instilling confidence that it lives up to their claims. We exist, after all, in an industry of hyperbole. It also doesn't help that their solution is layered on top of an operating system that has traditionally been managed in a very different way.
raffraffraff 3y ago
A friend of mine said that he is currently using it instead of packer at his current gig. He can use the same code to build any type of output, AMI, docker image, VM etc. I dig that. But I'm still not gonna learn nix because I don't do enough of that stuff to warrant the pain of learning nix.

gonehome 3y ago

This matches my experience with it so far. Extremely complicated and hard to understand, projects that use it have builds fail anyway except now with very hard to debug errors.

lillecarl 3y ago
When a nix build fails it'll fail with errors from the build system the package uses. The upside is that your failure is now reproducible.
- ParetoOptimal 3y ago
  Good point. I'm much more likely to help others because I know I can get to the exact state they are in and reproduce their issue with a simple `nix build`.
SuperSandro2000 3y ago
> Extremely complicated and hard to understand That is absolutely not true. If you start to get the hang of it and follow the way things are supposed to be done then things get easier over time. You need to invest upfront more time into your configuration but on the long run it pays off and saves you from an entire error class. > projects that use it have builds fail anyway The point of Nix/NixOS is not to have no failing builds but that those are reproducible and deterministic as much as possible and that those failures are noticed early and before the point of no return. A system build is supposed to fail early and not mid way through a major update and prompting you to merge some config under /etc by hand.
- thumbuddy 3y ago
  I've never seen it actually pay off in industry. I've seen it be used as good job security while other devs just wrote docker files and got things done.
  - skulk 3y ago
    Then you're not paying enough attention. There are plenty of companies using nix to distribute a reproducible environment (if you don't believe me, why not go search GitHub for "flake.nix" and see how many "industry" repos you find). I think it would be more productive for you to sit down and give it a fair chance than posting little rebukes all over this thread.
    - thumbuddy 3y ago
      I gave it a fair chance and it was a deciding factor in why I left a company believe it or not. Only one person could maintain and fix deployments. Not from lack of trying from seasoned experts and no new comers. It was the worst user experience I have probably ever encountered. Meanwhile I was able to pick up terraform and docker in a matter of days...
  - __MatrixMan__ 3y ago
    As the only guy maintaining the flake.nix in my team's repo, I don't think it's really contributing to my job security. I'm just happy that they don't mind the extra files and commits here and there because I value the ability to contribute from different devices without worrying about which versions of what are installed. Maybe it'll be job security if people start agreeing that downloading binary tools in in CI without a hash check is unacceptable attack surface, but until then it's just this weird thing I'm doing on the side. I do catch a lot of bugs where people are relying on dependencies that they happen to have installed but have not declared. It's the kind of thing that prevents newcomers from being successful out of the gate, or makes taking a local process and putting it in CI difficult, but fixing those is not exactly high visibility.
  - SuperSandro2000 3y ago

lillecarl 3y ago

You don't have to manage your system with NixOS to reap the benefits of Nix. It solves very real problems that very much exist, it might not exist if you're a one-man show deploying WordPress to GoDaddy though. Barrier to entry: 1. Run the nix installer 2. Enable flakes 3. cd project 4. nix run This ensures you run the package with every dependency except the kernel pinned to a hashed version. If dependency hell is not a problem for you, be happy!

awelkie 3y ago
Step two is not even necessary if you use zero-to-nix's installer. https://zero-to-nix.com/start/install https://zero-to-nix.com/start/install
- lillecarl 3y ago
  Yup, I just didn't wanna confuse the already pessimistic person by saying "use the unofficial installer" :)
thumbuddy 3y ago
You're omitting the entire thing about learning how to write nix. Which is nightmare fuel even for FP fans.
- SuperSandro2000 3y ago
  Unless you are attempting advanced things you don't need to know a lot about the language and how the more advanced things work.
- pxc 3y ago
  Imo the harder part is learning bespoke build processes that you may not own in order to get software that assumes it can perform arbitrary network access or other naughtiness at build time to build successfully in a restricted sandbox. The language is maybe a little strange at first but there's really not much to it.
- kaba0 3y ago

SuperSandro2000 3y ago

> The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. That's simple: nix is a package manager and the language used by the package manager, NixOS is a Linux distro. > It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. From someone who is working as a DevOps Engineer for some years and managing Linux servers for a few years longer that thought is incredible naive. The problem of undefined and undocumented system state is a fundamental problem I encounter everywhere especially bad with legacy systems. I often do things on them blind and just pray for the best outcome, realising months later that some system was broken by one change I did and no one realised that for months. > I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold less and the learning curve doesn't require half a decade. Got stuff to do! I thought the same first but unwedging Debian once a week on a different system is also not fun and a waste of time and having servers in some undefined state and no one who how the config is supposed to be and why or when it got changed, too. The result in the end is that every system is different and unique and your Ansible playbook to run a common and good thought out task succeeds on 15 VMs and sometimes completely blows up the 16th because no one could have thought that the state of configuration there is so widely different.

joshSzep 3y ago
Nix vs not Nix seems like a parallel to Infrastructure As Code (terraform for example) vs Cowboying the AWS Console. Is that a fair comparison?
- thumbuddy 3y ago
  Not really, unfortunately. In my opinion, Nix is more like using Haskell instead of whatever language your team is using to write software.
  - SuperSandro2000 3y ago
    I got pretty far the first year without really writing much nix code at all.

ParetoOptimal 3y ago

> In my opinion the problem it attempts to solve doesn't really exist. It does, but some people are good at numbing themselves to it. So they block losing a day or half day from lack of reproducibility out of their memory or recall it as "no big deal".

justinhj 3y ago
Nobody loses time on Nix issues?
- thumbuddy 3y ago
  I can say from personal experience I've seen many days devoted exclusively to Nix upkeep and maintenance. That was from junior people to people who had spent half a decade or so deeply in the community and using Nix for their daily driver.
  - pxc 3y ago
    I've never had to do much for Nix itself, but packaging something to build from source can often require quite some effort. Applications that use a pretty unconstrained build/install process upstream may expect to do a lot of things that are not allowed in the Nix build sandbox, like unconstrained network access and or overwriting files in existing packages on the system. To deal with that you really have to dive in, learn how the sausage gets made in the upstream package, make some choices about if/where to compromise, and then spend some time tweaking and debugging. That can be a pain and can definitely take a day or two. I've only had 'maintenance' issues with Nix itself on macOS, where OS upgrades routinely nuke Nix's hooks into the OS or add restrictions that break things. (But they do that to other package managers as well.)
    - ParetoOptimal 3y ago
      You can mitigate this to some extent by approaching it as described here: https://www.haskellforall.com/2022/08/incrementally-package-haskell-program.html https://www.haskellforall.com/2022/08/incrementally-package-... I think Graham Christensen had a blog post along these lines... I'll see if I can find it. Edit: I couldn't find it... but I thought someone made a blog post about gradual adoption of Nix into a codebase.

pmarreck 3y ago

You basically have two choices: you can take the complexity upfront, and in a predictable fashion by learning Nix, or you can deal with the complexity after the fact when you’re dealing with dependency hell and a deadline is looming and your boss and/or client is mad. The Nix language is basically JSON plus syntax sugar plus pure functions. A Nix derivation can be thought of as a super-powered lockfile that includes not just the versions of the dependencies, but also the build instructions and the environment in which to build them. The argument for Nix is basically the same argument as the one for writing pure functions as much as possible, or not doing so. Any amount of experience doing the former will demonstrate that it is superior. Now, Nix may be complex, and some of that may be reducible, but the fundamental idea of treating a build like a pure function is NOT reducible, and is well worth the effort of learning, because it will apply to ANY future pure build and dependency management tool

marcosdumay 3y ago

> In my opinion the problem it attempts to solve doesn't really exist. Almost all of Docker use-cases are for solving that same problem, but badly and with partial completeness. The lack of adoption is really not caused by lack of value.

earthling8118 3y ago

You can continue spending your time messing around with your system then. I learned nix in a short amount of time and it has supercharged my development workflows and reduced the overall complexity. I have too much stuff to get done to not use it.

preseinger 3y ago
supercharged!!! how much faster are your development workflows now, versus before? like 100x? how complex were your previous development workflows? what did that complexity manifest as? how has nix made it less complex? i'm excited to learn more

II2II 3y ago

Based upon how I manage my system, Nix appears to be something that I could use productively. The problem isn't so much of them being able to explain what the tool is, but one of them being instilling confidence that it lives up to their claims. We exist, after all, in an industry of hyperbole. It also doesn't help that their solution is layered on top of an operating system that has traditionally been managed in a very different way.

raffraffraff 3y ago

A friend of mine said that he is currently using it instead of packer at his current gig. He can use the same code to build any type of output, AMI, docker image, VM etc. I dig that. But I'm still not gonna learn nix because I don't do enough of that stuff to warrant the pain of learning nix.