3 ms·

It sounds like your issues with Nix stem from its steep adoption curve, rather than any technical concern. This _is_ a concern for a team that needs to manage i

by ar_lan 4y ago

It sounds like your issues with Nix stem from its steep adoption curve, rather than any technical concern. This _is_ a concern for a team that needs to manage it - I agree. I'm quite diehard in terms of personal Nix/NixOS use, but I hesitate to recommend to colleagues as a solution because the learning curve would likely reduce productivity for quite some time. That said - I do think that deterministic, declarative package/dependency management is the proper future, especially when it comes to runtime environments.

throwaway894345 4y ago
> It sounds like your issues with Nix stem from its steep adoption curve, rather than any technical concern Not only is it difficult to learn (although that's a huge problem), but it's also difficult to use. For instance, even once you've "learned Nix", inferring data types is an ongoing problem because there is no static type system. These obstacles are prohibitive for most organizations (because of the high-touch nature of build tooling). > This _is_ a concern for a team that needs to manage it The problem is that there isn't "one team that needs to manage it"; every team needs to touch the build definitions or else you're bottlenecking your development on one central team of Nix experts which is also an unacceptable tradeoff. If build tools weren't inherently high-touch, then the learning curve would be a much smaller problem.
- ar_lan 4y ago
  Sorry, I wasn't clear - I wasn't implying there should be a central team to manage it. One of the beauties of Nix is providing declarative dev environments in repositories, which means to fully embrace it each individual team should own it for themselves. At best a central team would be useful for managing an artifactory/cache + maybe company-wide nixpkgs, but in general singular teams need to decide for themselves if Nix is helpful + then manage it themselves.
  - throwaway894345 4y ago
    Agreed. It's just that when every team has to own their stuff, usability issues become a bigger problem and afaict the Nix team is not making much progress on usability (to the extent that it seems like they don't care about the organizational use case--as is their prerogative).

by ar_lan 4y ago

throwaway894345 4y ago

> It sounds like your issues with Nix stem from its steep adoption curve, rather than any technical concern Not only is it difficult to learn (although that's a huge problem), but it's also difficult to use. For instance, even once you've "learned Nix", inferring data types is an ongoing problem because there is no static type system. These obstacles are prohibitive for most organizations (because of the high-touch nature of build tooling). > This _is_ a concern for a team that needs to manage it The problem is that there isn't "one team that needs to manage it"; every team needs to touch the build definitions or else you're bottlenecking your development on one central team of Nix experts which is also an unacceptable tradeoff. If build tools weren't inherently high-touch, then the learning curve would be a much smaller problem.

ar_lan 4y ago
Sorry, I wasn't clear - I wasn't implying there should be a central team to manage it. One of the beauties of Nix is providing declarative dev environments in repositories, which means to fully embrace it each individual team should own it for themselves. At best a central team would be useful for managing an artifactory/cache + maybe company-wide nixpkgs, but in general singular teams need to decide for themselves if Nix is helpful + then manage it themselves.
- throwaway894345 4y ago
  Agreed. It's just that when every team has to own their stuff, usability issues become a bigger problem and afaict the Nix team is not making much progress on usability (to the extent that it seems like they don't care about the organizational use case--as is their prerogative).