> Nix has been around for two decades. It's more appropriate to ask what was the point of creating Docker, Ansible, virtualenv, etc. when Nix already existed.

Nix, after two decades, still has an incredibly sharp learning curve, especially to build your own packages. Docker has almost no learning curve, including creating your own images and sharing them with the world.

I disagree. Defining packages is pretty easy, e.g.

    with import <nixpkgs> {};
    runCommand "my-thing"
      {
        someSortOfSource = fetchurl {
          url = "https://example.com/thing.tar.gz";
          sha256 = "0000000000000000000000000000000000000000000000000000000000000000";
        };
        buildInputs = [ gcc python3 whatever-else-you-like ];
      }
      ''
        tar xzf "$someSortOfSource"
        cd whateverWasInThatTarball
        run whatever commands you like
        mv whatever-the-result-should-be "$out"
      ''

The actual commands can usually be copy/pasted from the README or INSTALL file of whatever project you're "packaging".

> Docker has almost no learning curve, including creating your own images and sharing them with the world.

It took me several attempts to learn Docker, and I'm still very much a newbie with it. To be fair, most of the difficulty I had was due to my misunderstandings; e.g. "surely nobody actually does that?" (e.g. "download entire OS just to run a command"; "ignore all the hashing and just fetch 'latest'"; "run 'apt-get -y update' without having any idea what it's going to do a week from now"; etc.)

Once Docker 'clicked' for me (i.e. I realised that indeed, people are doing that sort of stuff), it became much easier. It's also when I completely lost interest in Docker, and started using OCI containers instead (you can get remarkably far with just 'tar', 'sha256sum' and 'jq'!).

These days my only interaction with Docker is when other people's containers cause an outage at work, due to Docker blowing through all the disk space on our cloud servers. (Fun fact: you can resize AWS disk partitions on-the-fly, but not if they're 100% full, since the partition-editing commands try to allocate temp files)

Docker has no learning curve? I tried to use docker twice and both times it was incredible frustrating.

> Nix has been around for two decades. It's more appropriate to ask what was the point of creating Docker, Ansible, virtualenv, etc. when Nix already existed.

I'd say that the relative popularity of the tools is an indication of how well suited they were for the things that people actually wanted to do.

Nobody (exaggerating here for dramatic effect, but it probably applies to a large part of the unseen 99%: https://www.hanselman.com/blog/dark-matter-developers-the-un...) wants to have fully reproducible builds and a unified language for configuring everything like Nix attempts to do, or even have an OS that attempts to centralize those concepts, like NixOS does because a lot of it is alien to them.

They just want to run their PHP CRUD app in a vaguely predictable way that is less painful than what they've historically done (ship scripts through FTP, experience pain due to php.ini being different, or a system package not being present, or the system package being of a different version). Docker and other solutions like it are the closest that they can get to shipping their machine to prod, given that shipping VMs has more challenges, than just telling their clients or even their ops to just run a Docker container with some configuration.

Nor do they want rootless containers, or distroless containers or Podman or any of the other fancy solutions - they just want their Ubuntu userland and their app to sort of work, most of the time.

We had containers in one way or another long before Docker, for example, FreeBSD jails were pretty good. And yet, they never caught on, nor did FreeBSD outside of large corporations, because for the most part the developer experience just wasn't there. Then came along Docker and changed everything (with plenty of bumps along the way), now building and running your app is pretty simple:

  1. nano Dockerfile
  2. docker build -t some_image_tag .
  3. docker run some_image_tag
  (or, you know, push the image somewhere)

Now, the layers system is a mess, permissions management is a mess (hence lots of containers run as root), volumes aren't easily browsable but bind mounts are also problematic, orchestration is all over the place (Compose is nice for a single server but doesn't handle clusters, Swarm is nice for multiple servers but mostly dead, Nomad is weird because of HCL, Kubernetes is nice if it's someone else's problem but there be dragons if you can't just pay a cloud vendor to handle it for you) and it got a large amount of things wrong (e.g. "latest" tags), but it was still good enough and aligned with actually getting things done.

Additionally, most developers don't get paid for ensuring that their application will run in a stable and predictable manner 5 years from now. Most developers get paid for shipping that mediocre piece of software that their boss wants them to before the end of the week and having it work well enough so the company can earn some money, before they're told to move on and do something else the next week. I'm not saying that it's how things should be, but just the way they are, at least for a lot of people who don't tackle interesting problems yet still put food on the table.

That is the "tragedy of good enough" and why Nix, NixOS, jails, FreeBSD or anything else won't be as popular until vaguely low skilled developers can get easily started with them. Maybe things just need to cool down and become more stable, even Kubernetes has gotten less horrible thanks to Rancher/K3s in the last years, maybe in a decade package management and the way OSes are will be more approachable.

> That is the "tragedy of good enough" and why Nix, NixOS, jails, FreeBSD or anything else won't be as popular until vaguely low skilled developers can get easily started with them. Maybe things just need to cool down and become more stable

Right. The Dockerfile format is much less elegant than Nix, but it's easier to get started with, and can be used for most cases.

I don't necessarily see everyone _writing_ Nix. But I think one way Nix can gain in adoption with developers is Nix makes it easy to make dependencies available for working on a project.

I'd also point to git: many developers struggle to use git; and might use it for some time without an intuitive understanding. The network effects of GitHub have somehow been enough to make git a prominent tool, despite it being difficult to use.

I think as more Nix stuff becomes copy-pasteable, there are enough use cases which don't require deep understanding of Nix.