Nope nope nope. They're not fine. Nix is really really hard to use. I worked for a company that ran all the ops with Nix managed by some of the contributors. Every time I wanted to do something I'd have to get DevOps to do it for me. I've never ever had that level of difficulty doing stuff outside of a Nix environment and I really, really tried. Most of my colleagues who are fairly decent developers struggled with it too. It's the only tech I advise against when it's mentioned nowadays. And I want to like it.

On the other hand only Nix (to my knowledge) guarantees truly reproducible builds.

It helps that people who are into Nix most often use NixOS. NixOS is the only distro I've written packages for. It's not even particularly hard since there's a lot of inspiration to find in the official and community repos + people sharing personal configurations.

The UX wasn't the best but it's improving.

It remains extremely reliable which is not something that you could say of other systems.

I went all in and used NixOS too, but things like managing CI with Hydra, running perf tests on Nix ops clusters, debugging 10K+ Nix repos… you start to get it down and then things change like with flakes… and all the tools like Nix2Stack, Nix2Cabal, Nix2Docker, managing secrets, user profiles, none of it is existing knowledge you can bring or really take elsewhere. If you’re familiar with the ‘innovation token’ idea Nix would take all of them in my eyes for a project.

Docker is more pragmatic unless you spend hundreds of hours on Nix, in my opinion.

Sorry but the notion that the docs are fine is laughable. Most nix functions don't even have doc comments. You have to figure them out by delving into examples in the depths of github. Nix is in dire need of a culture of providing documentation comments, along with a tool that builds them into a website, like rustdoc or haddock.

If the problem is that it's difficult and the documentation is not making that difficulty simple enough to use, then the documents are not fine. Simple as.

If the problem is that it's difficult to learn to fly a fighter jet, and the documentation is not making it simple, the real problem is that the documentation is not fine. Simple as that.

As someone who has a recreational pilot license (sure, not jets, but still) you just reinforced the point of the previous comment rather than refute it for me.

Most pilot text books are absolutely horribly written, finding a good one takes significant effort. Reading just an ok book shines a light on how absolutely trash the majority of pilot text books are and that it is absolutely bad "documentation" that is partially to blame for it being difficult to learn.

I was trying to say, that some things are going to be hard for most people, because they're inherently a bit hard.

Just like inherent complexity in some software or business problems.

Maybe airplanes wasn't the best thing to compare with -- the comment below compares with C instead, maybe that's better. I never flew a plane.

When you frame it like that, the question then becomes "do you actually need the fighter jet?" and "why are all these people suggesting I use a fighter jet?"

That's pushing the analogy past where it breaks and missing the point. Take someone who has only ever written C-like code. Hand them a Scheme, maybe Racket. You expect them to initially have difficulty regardless of the quality of documentation. It's a different way of thinking about and doing things and there's a lot of it to deal with.

> The reality is that the docs are fine

then show me where `nix-env`'s `--arg` and `--argstr` is documented.

That's documented right in the man page.

  --arg name value
    This option is accepted by nix-env, nix-instantiate and nix-build. When 
    evaluating Nix expressions, the expression evaluator will automatically try to 
    call functions that it encounters. [...]

Also in the manual:

https://nixos.org/manual/nix/stable/command-ref/opt-common.h...

The ad-hoc solutions you're talking about are often highly usable, a virtue often forgotten by software evangelists. Nix's learning curve will keep away people who are disciplined in avoiding yak-shaving, as the language specific version enables productivity now. Maybe adding a layer on top of Nix, like create-react-app is to webpack, can make it a better option for immediate productivity oriented developers.

A positive of taking the nix brick road is if you get bored of software development you'll have enough yak fur to retire.