7 ms·

Recently I've been in various threads on HN complaining about how frustrating the Nix story is for development. I do not read this and go "This is a great idea

Recently I've been in various threads on HN complaining about how frustrating the Nix story is for development. I do not read this and go "This is a great idea and process!" I read this and say, "I can see how this might be better than the existing haskell toolchain. Cabal-dev has always been a bit of a compromise." (Edit: showing how long it's been since I have used Haskell in anger, cabal-dev got deprecated in favor of native sandboxing about 2 years ago, my bad.) Haskell seems to be the common thread for nearly all users of Nix I've encountered in the wild. Honestly, do other people read this and go, "This seems better than my current development toolchain?" ESPECIALLY if you're producing static binaries? As much as I criticize Maven, I'm not sure what this process buys you over maven except... well... what DOES it buy you over Maven dependency management? Unification with OS packages? It's not immutable, reproducible deploys. The deploy side is easy to render immutable and reproducible with layerd, controlled, tagged containers. It seems to be a story that's more about the build and dev side of things. Heck, I showed this to a co-worker and he said, "Wow, cabal must be really bad if someone was so frustrated by it that their solution was to change their OS." I don't mean to throw shade on the work that the Nix and NixOS people have been doing. I understand it has value to some people. It just seems very oversold as a solution to the problem of reproducible dev environments. And by adopting Nix, you MUST deploy your executable to something that can play nice with Nix's expectations, even if you are making a static executable. This seems like a heavy price to pay.

coolsunglasses 11y ago
Nobody's used cabal-dev in Haskell-land for ages. Cabal has had native sandboxing since mid-2013 and Stack is a more recent alternative. I'd argue Nix is nicer for everything but Haskell because the way Nix thinks about versions doesn't fit projects as neatly as one would think. As a Linux distro it's nifty (fully systemd-ified). Cabal sandboxes have "just worked" since release in my experience (my own, plus hundreds of IRC users I've helped).
- KirinDave 11y ago
  Sure, the last time I deployed Haskell for a paycheck it was still cabal-dev. I'm absolutely out of date there. But I sort of struggle to imagine using NixOS to ship products, as it would mandate every dev maintain a comparable NixOS environment for development. In a world where even editor choice can be contentious and user-facing Linux only runs well on a small handful of machine types, this seems a little unfair.
  - sciurus 11y ago
    You don't have to switch to NixOS; you can run the nix package manager on any linux distribution or on OS X. https://nixos.org/nix/ https://nixos.org/nix/ https://nixos.org/wiki/Nix_on_OS_X https://nixos.org/wiki/Nix_on_OS_X A development team has to standardize on some things. Everyone might use their own text editor, but everyone can't use their own dependency management system.
    - KirinDave 11y ago
      This does't actually answer any real criticism I leveled except... > but everyone can't use their own dependency management system. This is untrue. Different disciplines use different tools for dependency management and it's not clear to me that the world is crying out for a unification here. Golang developers use one, Nim developers use another. Java developers have different requirements still. Let's look at a pair of closely related langauges, Clojure and ClojureScript. While we might want a uniform method for DECLARING dependencies, the specific mechanisms used to fetch those dependencies may (and possibly should?) be different.
      - sciurus 11y ago
        I didn't say everyone globally, I said everyone on a development team, i.e. a group of people working together to build a product. Creating a reliable development environment for a team can be a PITA. That's why Vagrant, and more recently Docker, gained a lot of traction. People could use Nix to solve the same problem, like ris describes at https://news.ycombinator.com/item?id=10050681 https://news.ycombinator.com/item?id=10050681
ayberkt 11y ago
The thing about Nix is that it's the first project, as far as I know, that tries to solve the problem of package management with a fundamentally different approach. Most of the solutions to date were just okay: they worked with a tolerable degree of failure. A solution that works good enough is often a serious obstacle for developing a solution that works really well. E.g. Unix works just good enough to preclude the adoption of a new paradigm in OS'es such as Plan 9. Treating packages like immutable values sounds like a genuinely new idea. So what I think is that people don't go "this seems better than my current development toolchain", instead they think that the idea that underlies Nix might result in disproportionately more reliable tools in package management. That's worth fussing about. Disclaimer: I am not associated with Nix in any way.
- yenda 11y ago
  The first but not the last, there is also Guix the package manager and GuixSD the system distribution, which is written in Scheme, as well as all the package definitions. For lispers it is heaven.
  - mbrock 11y ago
    (Guix is based on Nix, by the way.)
  - KirinDave 11y ago
    I am assuredly a "lisper" and I really don't want to use anything based on Nix. I really dislike how statically linked executables are not portable on Nix. I'm less upset w.r.t. dynamic library management.
- geggam 11y ago
  I am sort of curious. What problems are you having with package managers that building decent packages wont solve ?
technomancy 11y ago
> As much as I criticize Maven, I'm not sure what this process buys you over maven except... well... what DOES it buy you over Maven dependency management? I agree that using Nix doesn't make sense for application development where all the dependencies are resolvable within the language runtime. (Provided the runtime itself can be well-specified in the project configuration and the language's dependency management system defaults to exact immutable declarations.) But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis. Personally Guix is more interesting to me as a way to keep my own stuff declarative rather than for sharing across a team of developers. But the cost doesn't seem too high if your application has external dependencies which traditional tools suck at; I've felt that pain and it isn't pretty.
- mercurial 11y ago
  > But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis. Surely you would just depend on the driver, which is most likely going to be written in your high-level language. A better point may be languages which rely a lot on C libraries (think Ruby and Python), and where having something like pip won't magically install the ImageMagick dependency your software needs.
  - technomancy 11y ago
    The driver's not much good on its own. Traditional dependency systems force you to track the version of the server itself outside the project's configuration.
    - mercurial 11y ago
      So? This kind of service often sits on a different box anyway in production.
      - 11y ago

coolsunglasses 11y ago

Nobody's used cabal-dev in Haskell-land for ages. Cabal has had native sandboxing since mid-2013 and Stack is a more recent alternative. I'd argue Nix is nicer for everything but Haskell because the way Nix thinks about versions doesn't fit projects as neatly as one would think. As a Linux distro it's nifty (fully systemd-ified). Cabal sandboxes have "just worked" since release in my experience (my own, plus hundreds of IRC users I've helped).

KirinDave 11y ago
Sure, the last time I deployed Haskell for a paycheck it was still cabal-dev. I'm absolutely out of date there. But I sort of struggle to imagine using NixOS to ship products, as it would mandate every dev maintain a comparable NixOS environment for development. In a world where even editor choice can be contentious and user-facing Linux only runs well on a small handful of machine types, this seems a little unfair.
- sciurus 11y ago
  You don't have to switch to NixOS; you can run the nix package manager on any linux distribution or on OS X. https://nixos.org/nix/ https://nixos.org/nix/ https://nixos.org/wiki/Nix_on_OS_X https://nixos.org/wiki/Nix_on_OS_X A development team has to standardize on some things. Everyone might use their own text editor, but everyone can't use their own dependency management system.
  - KirinDave 11y ago
    This does't actually answer any real criticism I leveled except... > but everyone can't use their own dependency management system. This is untrue. Different disciplines use different tools for dependency management and it's not clear to me that the world is crying out for a unification here. Golang developers use one, Nim developers use another. Java developers have different requirements still. Let's look at a pair of closely related langauges, Clojure and ClojureScript. While we might want a uniform method for DECLARING dependencies, the specific mechanisms used to fetch those dependencies may (and possibly should?) be different.
    - sciurus 11y ago
      I didn't say everyone globally, I said everyone on a development team, i.e. a group of people working together to build a product. Creating a reliable development environment for a team can be a PITA. That's why Vagrant, and more recently Docker, gained a lot of traction. People could use Nix to solve the same problem, like ris describes at https://news.ycombinator.com/item?id=10050681 https://news.ycombinator.com/item?id=10050681

ayberkt 11y ago

The thing about Nix is that it's the first project, as far as I know, that tries to solve the problem of package management with a fundamentally different approach. Most of the solutions to date were just okay: they worked with a tolerable degree of failure. A solution that works good enough is often a serious obstacle for developing a solution that works really well. E.g. Unix works just good enough to preclude the adoption of a new paradigm in OS'es such as Plan 9. Treating packages like immutable values sounds like a genuinely new idea. So what I think is that people don't go "this seems better than my current development toolchain", instead they think that the idea that underlies Nix might result in disproportionately more reliable tools in package management. That's worth fussing about. Disclaimer: I am not associated with Nix in any way.

yenda 11y ago
The first but not the last, there is also Guix the package manager and GuixSD the system distribution, which is written in Scheme, as well as all the package definitions. For lispers it is heaven.
- mbrock 11y ago
  (Guix is based on Nix, by the way.)
- KirinDave 11y ago
  I am assuredly a "lisper" and I really don't want to use anything based on Nix. I really dislike how statically linked executables are not portable on Nix. I'm less upset w.r.t. dynamic library management.
geggam 11y ago
I am sort of curious. What problems are you having with package managers that building decent packages wont solve ?

technomancy 11y ago

> As much as I criticize Maven, I'm not sure what this process buys you over maven except... well... what DOES it buy you over Maven dependency management? I agree that using Nix doesn't make sense for application development where all the dependencies are resolvable within the language runtime. (Provided the runtime itself can be well-specified in the project configuration and the language's dependency management system defaults to exact immutable declarations.) But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis. Personally Guix is more interesting to me as a way to keep my own stuff declarative rather than for sharing across a team of developers. But the cost doesn't seem too high if your application has external dependencies which traditional tools suck at; I've felt that pain and it isn't pretty.

mercurial 11y ago
> But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis. Surely you would just depend on the driver, which is most likely going to be written in your high-level language. A better point may be languages which rely a lot on C libraries (think Ruby and Python), and where having something like pip won't magically install the ImageMagick dependency your software needs.
- technomancy 11y ago
  The driver's not much good on its own. Traditional dependency systems force you to track the version of the server itself outside the project's configuration.
  - mercurial 11y ago
    So? This kind of service often sits on a different box anyway in production.
    - 11y ago