11 ms·

Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS an

by exdsq 5y ago

Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS and used Nix whenever I could to try and pick it up, but it's such a complex beast I felt it slowed everything down. Simple tasks that would take 10 minutes in Docker suddenly became DevOps tickets. I suddenly had to write bindings for tools rather than apt-get them in a Dockerfile. Build times in Haskell were bad enough but suddenly you had nix into the mix and I'd be wasting half a day as Nix built the entire world - solved with internal caching servers but have fun trying to work out how to push something to that correctly. There's a blog post that goes around from time to time about how a company have three risk tokens to allocate per project on non-boring technologies. Nix seriously needs all three. It's the only technology I've ever vetoed at a startup because I've seen the hell hole it can become - perhaps not for the DevOps engineers who know it, but the team who have to suddenly work within the resulting environment.

taeric 5y ago
Funny, because I feel that simple tasks that would take minutes in my machine are now a dev adventure with docker. And I mean funny. I suspect it is different mindsets. And I personally like that both seem to be thriving.
- goodpoint 5y ago
  It's well documented that Docker and especially docker hub had a terrible impact on security. Once you factor in the efforts required in the long term to mitigate a decade of bundling gigabytes of applications and libraries it's a huge "dev adventure"
  - oauea 5y ago
    Just build your own images like you would otherwise install the software on bare metal. Base those images on official images, not community images.
    - kryptk 5y ago
      YMMV. Personally, you would have to pry my Bitnami images out of my cold dead hands.. there is just no way my team of 2 can do anywhere near as good.
      - oauea 5y ago
        Fair, there are a few high quality "vendors" that we also trust, and Bitnami is one of them. RandomJoe42/SomeImage is out, though.
    - goodpoint 5y ago
      > Just build your own images This is like saying "just wear a mask": it's not enough. You rely on what other people are doing now and what they've done in the past. This is an ecosystem problem, not an an individual problem.
  - Frost1x 5y ago
    More like developer Towers of Babel waiting to collapse on every build attempt. Docker is fine if it's used correctly but it does add a layer of complexity, it doesn't abstract it away.. The way I see it rampantly (ab)used is as a shortcut to get some software up and running by leveraging a public image and passing tech debt for some component of one's system onto the maintainer of the Docker image, then cobbling together multistage builds from those and microservice architectures to try and support this tech debt model. Sometimes it works, many times it breaks, often it turns into complete and utter nightmares to deal with. "Amazing Andy got this fantastically complex system up and running in a week all by their self way under time and budget and it works. Now I just want to add this feature or modify this one thing and you're telling me that's going to take how long?" Yea, I've seen this more times than I care to admit.
    - kwertyoowiyop 5y ago
      “You mean Amazing Architect Andy who just left for Google?” :-(
      - KronisLV 5y ago
        That's at least partially why we have CV driven development be a thing in the industry. Either you jump on the NoSQL, AI, ML, blockchain, serverless, microservice, container, $FOO bandwagons, or you'll miss out on job opportunities and will have your CV stagnate. That's not to say that those technologies don't have good use cases in particular circumstances, it's just that you as an IC probably don't have strong incentives to care about where the project will be in 5-10 years when you will have left for another company in 2-3. A lot of accidental complexity is an unavoidable reality when you have people who put their own careers ahead of most other concerns.
- aspaceman 5y ago
  I feel similarly with Docker. But it's easier to explain to newer folks because it's only a single layer of abstraction above shell commands.
  - dnautics 5y ago
    I really wish something like singularity containers had taken over -- that was literally just shell commands.
    - mst 5y ago
      Possibly https://buildah.io/ https://buildah.io/ would be of interest.
      - dnautics 5y ago
        I do use podman, not really stoked about buildah because it's still a bunch of buildah commands in a shell-driven DSL, which I suppose is better than a dockerfile. Singularity was literally a build file that was a shell script divided into sections that denoted phases.
        mst 5y ago
        Bit late now but you could probably make something like it using buildkit - https://github.com/moby/buildkit/blob/master/examples/buildkit1/buildkit.go https://github.com/moby/buildkit/blob/master/examples/buildk...
  - taeric 5y ago
    I call this. It isn't a single abstraction over shell. It is a single closure over shell. And that is surprisingly hard to explain. Again, though, I am glad both are thriving. Competition of implementation is... not that compelling to me. Competition of approach, is amazing.
  - aequitas 5y ago
    The issue with simple solutions is that the underlying problem still has the same complexity. This complexity rises up sooner or later and depending on your abstraction will be nice caught within it or make a complete mess.
- oauea 5y ago
  If you can do it in minutes on your machine, you can spend those minutes updating your Dockerfile to automate the steps instead. It's essentially the same thing.
  - taeric 5y ago
    Unless auth is concerned. There are loads of tools I run that I want to just be me. Not whatever user is configured in the image. And learning how to manage that mapping was a heck of a time sink.
    - oauea 5y ago
      How you going to run those tools on CI? Or by your colleagues? These are all questions that need answering anyway, regardless of your usage of Docker.
      - taeric 5y ago
        I already authed as me on my machine. Annoying to also have to auth as me in the container. Or have we reached the stage where folks have secrets management for containers fully orchestrated at a personal user level?
lvass 5y ago
I've always kept my usage of Nix language to a minimum and found it to be a joy every time. But it's no wonder you'd have trouble on something that humongous. Why did it get so large?
- exdsq 5y ago
  Nix can do everything and that's an issue - suddenly the CI servers, AWS deployments, build servers, testing, linting, dev package management, dev system environments, and more are all written in Nix packages. You need to write nix bindings. You need to add nix caching. And, as is fitting with a functional language, it can be beautifully (read: painfully) abstract. Some of the guys on the team were contributors to Nix so it wasn't like we weren't following best practices either. I'm sure if everyone was willing to put in weeks/months of effort it'll be as fun to use as Haskell, but Nix isn't the thing I do so I need something simple - docker/docker-compose works perfectly well for that.
  - svenhy 5y ago
    No, Nix can't do everything, it can do the one thing it does, mainly it maintains immutable paths and allows to define derivations of any number of those paths using namespaced execution of build scripts. All this is controlled using expression in the Nix language, which is well suited for the intended purpose. It is in important aspect the opposite of Haskell. Nix does so well what it does, that it is easy to use it where better solution exists (looking at you NixOps) So I agree with some parts of your criticism, on the other hand if Nix is be used to do the sensible subset of "CI servers, AWS deployments, build servers, testing, linting, dev package management, dev system environments, and more are", that would be great. And what that subset is depends heavily on the given circumstances. For me, being able to derive the "CI servers, AWS deployments, build servers, testing, linting, dev package management, dev system environments" things from a single source of truth, actually does sell Nix pretty nicely. When approaching a complex, multi-component source repository, with the requirement for dev-environments, CI builds and generation of production ready Docker-images, a careful and not over-eager Nix build, seems a sensible choice, given that the layered nature of Dockerfiles and docker-compose obscures the DAG nature of built artifacts and dependencies. Nix also doesn't build anything by itself, it merely invokes low-level build tools in isolated environments that only contain the specified dependencies. Sure, when using Nix one is forced to explicitly state the dependencies of each (sub-component-) build-step, that results in more code than a bunch of RUN ... calls in Dockerfiles. Both approaches have their sweetspots. An investment into learning Nix is done once. And you are completely right, that refactoring to a Nix based build takes weeks in a serious legacy software project. I wonder myself, if this will be worth it. Currently, I think that might be the case, and that part of the weeks put into the build are not due to Nix and would have been necessary for Docker-based builds, too, and also one can do a lot of stuff much easier with Nix, which leads to "feature-creep" like "oh let me add this preconfigured vim/emacs/vs-code into the build env" that one would probably not do if it weren't so easy to customize everything with overlays and overrides. But that is a good thing, and it is much better to have a capable tool and critical discussions with colleagues to limit the usage of that tool, than the other way around. Heck, I remeber when we switched to a Maven build, and had a build with all bells and whistles. That took weeks, too, and all the generated artifacts, like source code documentation sites, were probably a waste if time to implement. I am not sure if that proves or disproves powerful, declarative and modular build systems. Dockerfiles and docker-compose.yamls have a learning curve too, but more importantly, if you have to invest more time per build maintenance than with a Nix based build, it is only a matter time until that costs more than the nix approach.
rgoulter 5y ago
> There's a blog post that goes around from time to time about how a company have three risk tokens to allocate per project on non-boring technologies. https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology
- exdsq 5y ago
  Thanks, this is the one! Highly recommend it, especially when you're in the HN echo chamber of new and interesting technologies
  - gurjeet 5y ago
    See also: http://boringtechnology.club/ http://boringtechnology.club/
  - amarshall 5y ago
    Worth noting in this context of OP, though, is that Nix predates Docker by about a decade.
    - eximius 5y ago
      That is extremely concerning, then, that it is so difficult to use after all that time. I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years".
      - beermonster 5y ago
        Is it? Or is it just a tool that requires a different mindset so those coming to it from another regular distro? If the latter, then I’m not sure it’s something they will see as a problem but more its very ethos.
        rgoulter 5y ago
        Maybe an apt comparison is git. It's just as easy to make a mistake with git today as it was however many years ago; git hasn't fundamentally changed in ways that make it easier. Git still more/less requires you to have a good understanding of what's going on in order to be comfortable using it. But, since use of git is now widespread, it's less of an issue. And the git CLI has seen some UX improvements. Nix is very weird. I'm sure there are some ways its UX could be nicer; but to some extent, doing things in a strict/pure way is always going to have friction if the tools/environments don't easily support that.
fulafel 5y ago
Was/would it be hard to switch back to traditional containers or was there some kind of lock-in effect? Or was the consensus just pro-Nix?
- exdsq 5y ago
  The conesnsus with those who mattered to make that change was pro-Nix, but I have no idea how you'd go back to containers because by that point builds were declarative and the implementation was spread over abstractions and repositories! So if DevOps decided to quit because another company was using SuperNix2, which I think is a plausible thing if you have a team using a risky technology, then it would have required hiring consultants to do it - I think it would have been a months-long refactor going in blind.
Barrin92 5y ago
>Build times in Haskell were bad enough this one's very true. Every time I try to build something in Haskell on my laptop it feels like we're moving closer to the heat death of the universe. Is there some good read on how/why Haskell compilation times are so long compared to some other languages?
- wereHamster 5y ago
  > moving closer to the heat death of the universe So… you're saying your laptop is super cool? Because the heat death of the universe is when thermodynamic energy is equally distributed everywhere, which, given the large space of the universe, means really cold.
  - solohan 5y ago
    Actually, the heat death is when all potential energy in the universe has been converted to heat. So converting an excess of stored chemical energy in their laptop battery to heat by compiling a load of Haskell would be a fine way of increasing the entropy of the Universe. Thus moving ever so slightly closer to the inevitable heat death.
  - deleted 5y ago
    [deleted]
  - xelxebar 5y ago
    Heh. Though while we're playing Pedantics, it's worth pointing out that the defining characteristic of Heat Death is maximum entropy, not uniform temperature. That said, it's entirely possible that the whole system of Energy Company + OP's computer actually does get cooler on average when compiling Haskell. Here's a fun game. Have you ever played Follow the Energy? For example, depressing keys on your keyboard takes energy. Where does that energy come from? Well, the work performed by your fingers of course! But where does that energy come from? Well, the muscles in your fingers, of course! But where does that come from? Well, your food! But what about that? Well, your food's food! That? Eventually plants. That? The sun! That? Nuclear fusion. That? Gravitational potential! That? Etc... But here's the funny thing. In this image, it kind of seems like energy gets "used up". The sun provides energy to the earth via solar radiation; the plants consume this energy; animals eat the plants, obtaining their energy; etc. However, energy is conserved. What gives? Better yet, if the earth were not radiating just as much energy as it received, it should be heating up. However, the earth-atmosphere system is mostly constant temperature! This implies that the total energy flux is zero. If X Watts (Energy/Time) is coming in, then the earth actually radiates out X Watts as well. So... if the total energy flux is zero, then how does your keyboard key actually get pressed? What gives? The key is entropy. X Watts of solar radiation impinge upon the earth, but these photons are "hotter" (i.e. higher frequency) on average than those that radiate out. The balance is in numbers. You need more cooler photons to balance the energy of the hotter ones. E=hf; energy (E) is proportional (constant h) to frequency (f), after all. This means that while energy is conserved, the flow of that energy increases the entropy of the system. In a very real sense, typing on your keyboard happens because of the waste heat generated in the process. All driving us closer to Heat Death...
throwaway894345 5y ago
This mirrors my experience as a developer in an org that used Nix. If you want the dev team to have a strong dependency on the devops team for every little (often unpredictable) aspect of their workflow, Nix is the tool for the job. Don’t get me wrong, I’m completely bought in on the vision of reproducible builds but there’s a long ways to go before it’s usable in real organizations. I’ve heard that some orgs manage it, but I really have no idea how. Maybe some critical mass of people who already know and love Nix (and implicitly packaging obscure dependencies)?
- vineyardmike 5y ago
  Many orgs get reproducible builds by using different build tools and abstractions. Eg Amazon gets it via their Brazil tool.
  - throwaway894345 5y ago
    I was talking about Nix in particular, but yes, if you’re an enormous and highly lucrative tech company you can pay a team of engineers to build your own reproducible build tool. If the same team is very talented they can probably even get Bazel working. ;) But I don’t think any large orgs at all use Nix, presumably because it doesn’t scale beyond a small number of (enthusiastic) developers.
- hitpointdrew 5y ago
  > If you want the dev team to have a strong dependency on the devops team for every little (often unpredictable) aspect of their workflow, I have never used nix, but from the article the author only concentrated on the fact that docker and nix create reproducible environments, and completely misses the other benefits of containers. As a devops guy if someone hands me a nix project, how do I deploy that so it is highly available and scales by itself? With containers I just put it in kubernetes.
  - Nullabillity 5y ago
    You can use Nix as a better docker build, see https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images or https://nixery.dev/ https://nixery.dev/.
chriswarbo 5y ago
> apt-get them in a Dockerfile > Nix built the entire world You're comparing apples to oranges. Docker just runs commands. If you want to run commands, you can do that in Nix using e.g. nixpkgs.runCommand. apt-get just fetches prebuilt binaries. If you want to fetch prebuilt binaries, you can do that in Nix using e.g. nixpkgs.fetchurl. You can even use runCommand to run apt-get (I do this to use Debian's Chromium package on 32bit NixOS) In contrast, it sounds like you were using Nix as a build tool, to define your entire OS from scratch (presumably using Nixpkgs/NixOS). In which case apt-get isn't a comparable command; instead, the Debian equivalent would be: apt-build world Guess what that does?
- deleted 5y ago
  [deleted]
nvarsj 5y ago
I'd say don't blame the tool for what sounds like an architectural mess. TFA points out using nix as a reproducible build environment - which it is excellent at. Create a shell.nix in your repo, and every dev uses the same exact tools within the comfort of their own machine/shell. Docker is much more painful for this kind of local dev workflow.
- exdsq 5y ago
  Potentially it was a mess, but the guys building it contribute to nix so I don’t think that’s to blame. Dev environments are okay, but that’s not the limit of nix - it gets used for build servers, ci servers, linting, replacing stack cabal yarn etc, creating docker, hell I’m pretty sure I saw nix creating nix
temptemptemp111 5y ago
Right, they're hiding complexity. If you look at my recent comments in a related thread - everyone was arguing against me for even attempting to compare Nix and Docker ("you're comparing things that aren't meant to be compared" basically). Now those same people are commenting in this thread in favor of Nix as a solution. Such dishonesty & delusion!
kaladin-jasnah 5y ago
I truly hope not as well. I spent an extensive period of time trying to learn Nix and integrate it into my homelab. Granted, it's not an enterprise environment, but it is the most painful, unstable, broken, buggy, bloated, hard-to-use, poorly-documented mess I've ever tried. I hope no one touches Nix with a ten-foot pole. That's not to say it's not a great idea. It's just a huge pain to get to work, and the cost of trying to get a perfectly-working Nix environment is just *not* worth it. In my case, I was working with orchestrating virtual machines, which… well, there's a project called nixops that claims to do this. The thing is it flat-out didn't work half the time (also used python2.7 and I believe one of its dependencies were marked as insecure for a long period of time). I got so frustrated with this "advertised" nixops tool, that had to write my own replacement for nixops, and while it was a fun experience, I was so burnt-out from dealing with Nix and its breaking randomly every ten seconds, I just gave up on my homelab. If you want any program that doesn't exist for Nix, you can't just use the program's build script. You have to manually make a Nix derivation, and then pray and hope it will actually compile. Want to deploy your Ruby on Rails application on NixOS? Prepare to spend three days trying to set this up, since there's only one other application and the entire process is poorly documented (even for a "regular" Ruby program that isn't Rails). Without additional work, Nix will never be worth its cost (did I mention the interpreter took forever and sometimes failed on errors in files that had NOTHING to do with yours, leaving you to manually debug each line?). You could spend the days upon days upon days trying to get the damned thing to work for something far more useful instead. Since once you get Nix to work, it will break. I'm sorry if I offended any Nix users/developers, but the product is just not ready for anything yet IMHO. I just don't have time to deal with it anymore, and I'd rather get on doing something more fun than dealing with a bloated, undocumented system that I can just replace with Docker and get my work done in 5 minutes instead of 5 days.
- pxc 5y ago
  > did I mention the interpreter took forever and sometimes failed on errors in files that had NOTHING to do with yours, leaving you to manually debug each line? This is a common (and horrible) issue with dynamic languages that pass functions or blocks of code around. There have been some major improvements to Nix error messages which were included in the last release, and there's also ongoing work to address this through gradual typing. There was a talk on the latter recently, with some examples that I think make the overall issue pretty clear: https://www.youtube.com/watch?v=B0J-SclpRYE https://www.youtube.com/watch?v=B0J-SclpRYE

by exdsq 5y ago

taeric 5y ago

Funny, because I feel that simple tasks that would take minutes in my machine are now a dev adventure with docker. And I mean funny. I suspect it is different mindsets. And I personally like that both seem to be thriving.

goodpoint 5y ago
It's well documented that Docker and especially docker hub had a terrible impact on security. Once you factor in the efforts required in the long term to mitigate a decade of bundling gigabytes of applications and libraries it's a huge "dev adventure"
- oauea 5y ago
  Just build your own images like you would otherwise install the software on bare metal. Base those images on official images, not community images.
  - kryptk 5y ago
    YMMV. Personally, you would have to pry my Bitnami images out of my cold dead hands.. there is just no way my team of 2 can do anywhere near as good.
    - oauea 5y ago
      Fair, there are a few high quality "vendors" that we also trust, and Bitnami is one of them. RandomJoe42/SomeImage is out, though.
  - goodpoint 5y ago
    > Just build your own images This is like saying "just wear a mask": it's not enough. You rely on what other people are doing now and what they've done in the past. This is an ecosystem problem, not an an individual problem.
- Frost1x 5y ago
  More like developer Towers of Babel waiting to collapse on every build attempt. Docker is fine if it's used correctly but it does add a layer of complexity, it doesn't abstract it away.. The way I see it rampantly (ab)used is as a shortcut to get some software up and running by leveraging a public image and passing tech debt for some component of one's system onto the maintainer of the Docker image, then cobbling together multistage builds from those and microservice architectures to try and support this tech debt model. Sometimes it works, many times it breaks, often it turns into complete and utter nightmares to deal with. "Amazing Andy got this fantastically complex system up and running in a week all by their self way under time and budget and it works. Now I just want to add this feature or modify this one thing and you're telling me that's going to take how long?" Yea, I've seen this more times than I care to admit.
  - kwertyoowiyop 5y ago
    “You mean Amazing Architect Andy who just left for Google?” :-(
    - KronisLV 5y ago
      That's at least partially why we have CV driven development be a thing in the industry. Either you jump on the NoSQL, AI, ML, blockchain, serverless, microservice, container, $FOO bandwagons, or you'll miss out on job opportunities and will have your CV stagnate. That's not to say that those technologies don't have good use cases in particular circumstances, it's just that you as an IC probably don't have strong incentives to care about where the project will be in 5-10 years when you will have left for another company in 2-3. A lot of accidental complexity is an unavoidable reality when you have people who put their own careers ahead of most other concerns.
aspaceman 5y ago
I feel similarly with Docker. But it's easier to explain to newer folks because it's only a single layer of abstraction above shell commands.
- dnautics 5y ago
  I really wish something like singularity containers had taken over -- that was literally just shell commands.
  - mst 5y ago
    Possibly https://buildah.io/ https://buildah.io/ would be of interest.
    - dnautics 5y ago
      I do use podman, not really stoked about buildah because it's still a bunch of buildah commands in a shell-driven DSL, which I suppose is better than a dockerfile. Singularity was literally a build file that was a shell script divided into sections that denoted phases.
      - mst 5y ago
        Bit late now but you could probably make something like it using buildkit - https://github.com/moby/buildkit/blob/master/examples/buildkit1/buildkit.go https://github.com/moby/buildkit/blob/master/examples/buildk...
- taeric 5y ago
  I call this. It isn't a single abstraction over shell. It is a single closure over shell. And that is surprisingly hard to explain. Again, though, I am glad both are thriving. Competition of implementation is... not that compelling to me. Competition of approach, is amazing.
- aequitas 5y ago
  The issue with simple solutions is that the underlying problem still has the same complexity. This complexity rises up sooner or later and depending on your abstraction will be nice caught within it or make a complete mess.
oauea 5y ago
If you can do it in minutes on your machine, you can spend those minutes updating your Dockerfile to automate the steps instead. It's essentially the same thing.
- taeric 5y ago
  Unless auth is concerned. There are loads of tools I run that I want to just be me. Not whatever user is configured in the image. And learning how to manage that mapping was a heck of a time sink.
  - oauea 5y ago
    How you going to run those tools on CI? Or by your colleagues? These are all questions that need answering anyway, regardless of your usage of Docker.
    - taeric 5y ago
      I already authed as me on my machine. Annoying to also have to auth as me in the container. Or have we reached the stage where folks have secrets management for containers fully orchestrated at a personal user level?

lvass 5y ago

I've always kept my usage of Nix language to a minimum and found it to be a joy every time. But it's no wonder you'd have trouble on something that humongous. Why did it get so large?

exdsq 5y ago
Nix can do everything and that's an issue - suddenly the CI servers, AWS deployments, build servers, testing, linting, dev package management, dev system environments, and more are all written in Nix packages. You need to write nix bindings. You need to add nix caching. And, as is fitting with a functional language, it can be beautifully (read: painfully) abstract. Some of the guys on the team were contributors to Nix so it wasn't like we weren't following best practices either. I'm sure if everyone was willing to put in weeks/months of effort it'll be as fun to use as Haskell, but Nix isn't the thing I do so I need something simple - docker/docker-compose works perfectly well for that.
- svenhy 5y ago
  No, Nix can't do everything, it can do the one thing it does, mainly it maintains immutable paths and allows to define derivations of any number of those paths using namespaced execution of build scripts. All this is controlled using expression in the Nix language, which is well suited for the intended purpose. It is in important aspect the opposite of Haskell. Nix does so well what it does, that it is easy to use it where better solution exists (looking at you NixOps) So I agree with some parts of your criticism, on the other hand if Nix is be used to do the sensible subset of "CI servers, AWS deployments, build servers, testing, linting, dev package management, dev system environments, and more are", that would be great. And what that subset is depends heavily on the given circumstances. For me, being able to derive the "CI servers, AWS deployments, build servers, testing, linting, dev package management, dev system environments" things from a single source of truth, actually does sell Nix pretty nicely. When approaching a complex, multi-component source repository, with the requirement for dev-environments, CI builds and generation of production ready Docker-images, a careful and not over-eager Nix build, seems a sensible choice, given that the layered nature of Dockerfiles and docker-compose obscures the DAG nature of built artifacts and dependencies. Nix also doesn't build anything by itself, it merely invokes low-level build tools in isolated environments that only contain the specified dependencies. Sure, when using Nix one is forced to explicitly state the dependencies of each (sub-component-) build-step, that results in more code than a bunch of RUN ... calls in Dockerfiles. Both approaches have their sweetspots. An investment into learning Nix is done once. And you are completely right, that refactoring to a Nix based build takes weeks in a serious legacy software project. I wonder myself, if this will be worth it. Currently, I think that might be the case, and that part of the weeks put into the build are not due to Nix and would have been necessary for Docker-based builds, too, and also one can do a lot of stuff much easier with Nix, which leads to "feature-creep" like "oh let me add this preconfigured vim/emacs/vs-code into the build env" that one would probably not do if it weren't so easy to customize everything with overlays and overrides. But that is a good thing, and it is much better to have a capable tool and critical discussions with colleagues to limit the usage of that tool, than the other way around. Heck, I remeber when we switched to a Maven build, and had a build with all bells and whistles. That took weeks, too, and all the generated artifacts, like source code documentation sites, were probably a waste if time to implement. I am not sure if that proves or disproves powerful, declarative and modular build systems. Dockerfiles and docker-compose.yamls have a learning curve too, but more importantly, if you have to invest more time per build maintenance than with a Nix based build, it is only a matter time until that costs more than the nix approach.

rgoulter 5y ago

> There's a blog post that goes around from time to time about how a company have three risk tokens to allocate per project on non-boring technologies. https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology

exdsq 5y ago
Thanks, this is the one! Highly recommend it, especially when you're in the HN echo chamber of new and interesting technologies
- gurjeet 5y ago
  See also: http://boringtechnology.club/ http://boringtechnology.club/
- amarshall 5y ago
  Worth noting in this context of OP, though, is that Nix predates Docker by about a decade.
  - eximius 5y ago
    That is extremely concerning, then, that it is so difficult to use after all that time. I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years".
    - beermonster 5y ago
      Is it? Or is it just a tool that requires a different mindset so those coming to it from another regular distro? If the latter, then I’m not sure it’s something they will see as a problem but more its very ethos.
      - rgoulter 5y ago
        Maybe an apt comparison is git. It's just as easy to make a mistake with git today as it was however many years ago; git hasn't fundamentally changed in ways that make it easier. Git still more/less requires you to have a good understanding of what's going on in order to be comfortable using it. But, since use of git is now widespread, it's less of an issue. And the git CLI has seen some UX improvements. Nix is very weird. I'm sure there are some ways its UX could be nicer; but to some extent, doing things in a strict/pure way is always going to have friction if the tools/environments don't easily support that.

fulafel 5y ago

Was/would it be hard to switch back to traditional containers or was there some kind of lock-in effect? Or was the consensus just pro-Nix?

exdsq 5y ago
The conesnsus with those who mattered to make that change was pro-Nix, but I have no idea how you'd go back to containers because by that point builds were declarative and the implementation was spread over abstractions and repositories! So if DevOps decided to quit because another company was using SuperNix2, which I think is a plausible thing if you have a team using a risky technology, then it would have required hiring consultants to do it - I think it would have been a months-long refactor going in blind.

Barrin92 5y ago

>Build times in Haskell were bad enough this one's very true. Every time I try to build something in Haskell on my laptop it feels like we're moving closer to the heat death of the universe. Is there some good read on how/why Haskell compilation times are so long compared to some other languages?

wereHamster 5y ago
> moving closer to the heat death of the universe So… you're saying your laptop is super cool? Because the heat death of the universe is when thermodynamic energy is equally distributed everywhere, which, given the large space of the universe, means really cold.
- solohan 5y ago
  Actually, the heat death is when all potential energy in the universe has been converted to heat. So converting an excess of stored chemical energy in their laptop battery to heat by compiling a load of Haskell would be a fine way of increasing the entropy of the Universe. Thus moving ever so slightly closer to the inevitable heat death.
- deleted 5y ago
  [deleted]
- xelxebar 5y ago
  Heh. Though while we're playing Pedantics, it's worth pointing out that the defining characteristic of Heat Death is maximum entropy, not uniform temperature. That said, it's entirely possible that the whole system of Energy Company + OP's computer actually does get cooler on average when compiling Haskell. Here's a fun game. Have you ever played Follow the Energy? For example, depressing keys on your keyboard takes energy. Where does that energy come from? Well, the work performed by your fingers of course! But where does that energy come from? Well, the muscles in your fingers, of course! But where does that come from? Well, your food! But what about that? Well, your food's food! That? Eventually plants. That? The sun! That? Nuclear fusion. That? Gravitational potential! That? Etc... But here's the funny thing. In this image, it kind of seems like energy gets "used up". The sun provides energy to the earth via solar radiation; the plants consume this energy; animals eat the plants, obtaining their energy; etc. However, energy is conserved. What gives? Better yet, if the earth were not radiating just as much energy as it received, it should be heating up. However, the earth-atmosphere system is mostly constant temperature! This implies that the total energy flux is zero. If X Watts (Energy/Time) is coming in, then the earth actually radiates out X Watts as well. So... if the total energy flux is zero, then how does your keyboard key actually get pressed? What gives? The key is entropy. X Watts of solar radiation impinge upon the earth, but these photons are "hotter" (i.e. higher frequency) on average than those that radiate out. The balance is in numbers. You need more cooler photons to balance the energy of the hotter ones. E=hf; energy (E) is proportional (constant h) to frequency (f), after all. This means that while energy is conserved, the flow of that energy increases the entropy of the system. In a very real sense, typing on your keyboard happens because of the waste heat generated in the process. All driving us closer to Heat Death...

throwaway894345 5y ago

This mirrors my experience as a developer in an org that used Nix. If you want the dev team to have a strong dependency on the devops team for every little (often unpredictable) aspect of their workflow, Nix is the tool for the job. Don’t get me wrong, I’m completely bought in on the vision of reproducible builds but there’s a long ways to go before it’s usable in real organizations. I’ve heard that some orgs manage it, but I really have no idea how. Maybe some critical mass of people who already know and love Nix (and implicitly packaging obscure dependencies)?

vineyardmike 5y ago
Many orgs get reproducible builds by using different build tools and abstractions. Eg Amazon gets it via their Brazil tool.
- throwaway894345 5y ago
  I was talking about Nix in particular, but yes, if you’re an enormous and highly lucrative tech company you can pay a team of engineers to build your own reproducible build tool. If the same team is very talented they can probably even get Bazel working. ;) But I don’t think any large orgs at all use Nix, presumably because it doesn’t scale beyond a small number of (enthusiastic) developers.
hitpointdrew 5y ago
> If you want the dev team to have a strong dependency on the devops team for every little (often unpredictable) aspect of their workflow, I have never used nix, but from the article the author only concentrated on the fact that docker and nix create reproducible environments, and completely misses the other benefits of containers. As a devops guy if someone hands me a nix project, how do I deploy that so it is highly available and scales by itself? With containers I just put it in kubernetes.
- Nullabillity 5y ago
  You can use Nix as a better docker build, see https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images or https://nixery.dev/ https://nixery.dev/.

chriswarbo 5y ago

> apt-get them in a Dockerfile > Nix built the entire world You're comparing apples to oranges. Docker just runs commands. If you want to run commands, you can do that in Nix using e.g. nixpkgs.runCommand. apt-get just fetches prebuilt binaries. If you want to fetch prebuilt binaries, you can do that in Nix using e.g. nixpkgs.fetchurl. You can even use runCommand to run apt-get (I do this to use Debian's Chromium package on 32bit NixOS) In contrast, it sounds like you were using Nix as a build tool, to define your entire OS from scratch (presumably using Nixpkgs/NixOS). In which case apt-get isn't a comparable command; instead, the Debian equivalent would be: apt-build world Guess what that does?

deleted 5y ago
[deleted]

nvarsj 5y ago

I'd say don't blame the tool for what sounds like an architectural mess. TFA points out using nix as a reproducible build environment - which it is excellent at. Create a shell.nix in your repo, and every dev uses the same exact tools within the comfort of their own machine/shell. Docker is much more painful for this kind of local dev workflow.

exdsq 5y ago
Potentially it was a mess, but the guys building it contribute to nix so I don’t think that’s to blame. Dev environments are okay, but that’s not the limit of nix - it gets used for build servers, ci servers, linting, replacing stack cabal yarn etc, creating docker, hell I’m pretty sure I saw nix creating nix

temptemptemp111 5y ago

Right, they're hiding complexity. If you look at my recent comments in a related thread - everyone was arguing against me for even attempting to compare Nix and Docker ("you're comparing things that aren't meant to be compared" basically). Now those same people are commenting in this thread in favor of Nix as a solution. Such dishonesty & delusion!

kaladin-jasnah 5y ago

I truly hope not as well. I spent an extensive period of time trying to learn Nix and integrate it into my homelab. Granted, it's not an enterprise environment, but it is the most painful, unstable, broken, buggy, bloated, hard-to-use, poorly-documented mess I've ever tried. I hope no one touches Nix with a ten-foot pole. That's not to say it's not a great idea. It's just a huge pain to get to work, and the cost of trying to get a perfectly-working Nix environment is just *not* worth it. In my case, I was working with orchestrating virtual machines, which… well, there's a project called nixops that claims to do this. The thing is it flat-out didn't work half the time (also used python2.7 and I believe one of its dependencies were marked as insecure for a long period of time). I got so frustrated with this "advertised" nixops tool, that had to write my own replacement for nixops, and while it was a fun experience, I was so burnt-out from dealing with Nix and its breaking randomly every ten seconds, I just gave up on my homelab. If you want any program that doesn't exist for Nix, you can't just use the program's build script. You have to manually make a Nix derivation, and then pray and hope it will actually compile. Want to deploy your Ruby on Rails application on NixOS? Prepare to spend three days trying to set this up, since there's only one other application and the entire process is poorly documented (even for a "regular" Ruby program that isn't Rails). Without additional work, Nix will never be worth its cost (did I mention the interpreter took forever and sometimes failed on errors in files that had NOTHING to do with yours, leaving you to manually debug each line?). You could spend the days upon days upon days trying to get the damned thing to work for something far more useful instead. Since once you get Nix to work, it will break. I'm sorry if I offended any Nix users/developers, but the product is just not ready for anything yet IMHO. I just don't have time to deal with it anymore, and I'd rather get on doing something more fun than dealing with a bloated, undocumented system that I can just replace with Docker and get my work done in 5 minutes instead of 5 days.

pxc 5y ago
> did I mention the interpreter took forever and sometimes failed on errors in files that had NOTHING to do with yours, leaving you to manually debug each line? This is a common (and horrible) issue with dynamic languages that pass functions or blocks of code around. There have been some major improvements to Nix error messages which were included in the last release, and there's also ongoing work to address this through gradual typing. There was a talk on the latter recently, with some examples that I think make the overall issue pretty clear: https://www.youtube.com/watch?v=B0J-SclpRYE https://www.youtube.com/watch?v=B0J-SclpRYE