I'm a nix fan and have been using nixos for years now, packaging stuff and writing my own nix-based libraries, but I still find the language to be painful.

The problem is, documentation is sparse to non-existant, error messages are poor and often far from the actual problem, and it makes use of concept that lots of people are not familiar with (like lazy evaluation) without ever explaining them, resulting in surprising semantics.

But as far as I can tell, the nix devs are fully aware of these issues - they are affected by it too! The problem is, solving each of those issues is hard, and requires a lot of focused efforts.

> The problem is, documentation is sparse to non-existant, error messages are poor and often far from the actual problem, and it makes use of concept that lots of people are not familiar with (like lazy evaluation) without ever explaining them, resulting in surprising semantics.

Absolutely, that is the major roadblock for Nix/OS in my opinion, with the new `nix` command, the documentation is way better but the language and OS documentation is still bad, if you search for something on a search engine, the top result will probably be the NixOS Wiki which is not even official! Manuals can come up but the title for the nix manual (not NixOS) is "NixOS - Nix 2.3.15 Manual" which is confusing by itself but even more so when you're trying to solve a specific problem and not just get the manual. Having the "NixOS" part at the end for example would already help. Having titles for different parts of the manuals would be best. However, manuals are single pages except for the new nix command manual. That is a truly horrible user experience in my opinion... NixOS is however very good in other areas so the experience is positive in general but if resolution of issues could be faster, it would help significantly. My guess is that they will push towards the new manual format, so this will get resolved eventually but it will probably take a long time.

They are also probably not aware of certain issues like the fact that having no roadmap is not great for end users or contributors and doesn't create this focused effort that is required to solve the issues mentioned. Nix devs seem to be a bit too technical which is becoming a problem. If you guix to nix, they are much more organized, if you go to their homepage and want to contribute, it is very clear where you can contribute and how. Another example would be flakes. They created quite a hard split in the community between people that are using them and people that are not. They have some problems sure, but I think they should become standard and then be iterated upon. To summarize, the Nix/OS project feels to me like it is still treated like a research project with no users and few contributors which is not the case.

> The problem is, documentation is sparse to non-existant, error messages are poor and often far from the actual problem, and it makes use of concept that lots of people are not familiar with (like lazy evaluation) without ever explaining them, resulting in surprising semantics.

I used NixOS and Home-Manager to run my entire system and home directory for a couple weeks earlier this year. The lack of clear documentation made me leave. Most of the time to find relevant information I'd have to go in some chat room since often the "official" documentation would be outdated. If the documentation was better I'd probably still be on it.

All the official documentation is autogenerated daily. What documentation did you find outdated?

Autogenerated documentation !== up-to-date and/or good documentation.

Autogenerated means "we take these particular strings and texts and dump them in a different format". It says nothing about whether they are even remotely up to date.

Sure, but in my experience the documentation from the source has always been correct. There is tons of stuff on other websites that is outdated, but the source documentation has not suffered the same atrophy.

More importantly, much of the documentation is auto generated not from arbitrary doc strings, but from the nix expressions themselves. IE: https://search.nixos.org/options?

So I believe there was another source of the misinformation then the official docs.

One example: nix-pills introduces nix-env -i[1] as the third "pill" -- isn't this basically deprecated and never recommended by serious uesrs?

[1]: https://nixos.org/guides/nix-pills/enter-environment.html

Most probably NixOS Wiki, it's not official but always comes up as the top result because the manual's titles are irrelevent when you're trying to solve a specific issue. The NixOS Wiki is very helpful in a lot of ways (there is more info than in the manuals and you don't have to troubleshoot for hours because you missed activating some options), butit is true that it is sometimes outdated :/

Too that I say look at react hooks. Somehow the React devs managed to introduce functional concepts into a framework without anyone knowing why or how this black magic trick works. At the time of introduction I was heavily interested in functional approaches, mainly the solutions from Haskell. And now nobody gives a a damn how hooks works in JS only that they make the coding somewhat easier and nicer. (I‘m no JS developer and how no real world view at the current stage anymore).

Regarding nix. I love the idea and the project. Tried it 3 times with various issues which stopped me from using it (last time I was not able to compile a rust program because of some weird c runtime library which was pulled with the wrong version from wherever by whoever). My second bigger issue with nix is the fact that you have to go all the way or it makes no real sense. Mixing nix with Ubuntu or base arch is of course possible. But the developing python or whatever whichever means to install and manage the whole toolchain and project dependencies also with nix. I still check the project every now and then.

nix has been around for 18 years. If the documentation is still sparse after all these years, it's not a problem that will be fixed, ever. Same for explaining concepts.

Proper errors are a huge and poorly understood problem, so I'm inclined not to judge those too harshly.

I don't think it is fair to judge a project for the number of years its been around, specially for something that is really novel and innovative. Nix/NixOS is not a new web framework that most of concepts are really clear for everyone working with Web. It is a brand new concept for Operating Systems, however most people don't have a clue about system immutability and reproducibility and why this is so hard.

Of course, this doesn't excuse the state of the documentation that should be better. It is just that nobody ever documented this kinda of things before, so it is difficult to do it better.

Nix and NixOS just started to get more known and become popular from the last ~5 years or so, and I think this made the whole community aware that documentation is an issue and it is getting better and better (but maybe not at the pace most people wanted).

> defined boolean expression reference true.

“Defined” means the configuration is set, as opposed to unset or undefined

“Boolean” is a type, so the setting can be either true or false

“Expression” is the value of the setting, in this case true

“Reference” is a button that opens up the documentation for this particular setting

If you keep telling yourself nix is hard then it will be hard

You probably don't have a problem that this solves.

I.e., some people still download random zipfiles from the internet and install each individual app from a wizard dialog onto their Windows 10 machine. They find software repositories and package managers confusing and overengineered. I guess that's okay.

I don't find package managers confusing but I do, in fact, find them overengineered. They solve at most 75% of application management problems with the fallback for the other 25% being "compile it from source yourself" and it takes an army of unpaid third party maintainers to pull that off.

In my current estimation, Nix just solves an additional 5% at the cost of exponentially more overengineering.

> You probably don't have a problem that this solves.

> They find software repositories and package managers confusing and overengineered.

The screenshot is literally a mishmash of technical jargon with little to no relation to each other.

sound.enable defined boolean asset resource enabled.

What problem does it solve, exactly?

If you think the words software repository and package manager are esoteric technical jargon then you don't need nix, which is completely fine. But it allows developers to identically reproduce builds of a software which depends on other software packages. Other package managers may depend on some global variables of your system, which nix avoids.

That's like asking "what problem does apt-get solve, exactly, with its technical jargon, when I can always download the software I want using Google Chrome?"

Yeah but here it's the level of jargon that is the problem, there is too much! This is a good project for sure but it is not ready for new users.

Honestly, that's so patronising I wonder if you are trolling?

I use Debian and Redhat happily, also do plenty of Docker. I really want to love Nix and have tried a few times (even submitting some package updates), but just kept bouncing off it and giving up.

Good for you. That means you haven't encountered a problem that Nix is designed to solve.

(Nix is very much a "worse is better" tool in the tradition of hacking something together out of existing tools until you a minimal working product. It's designed to solve a particular class of problems quickly and painlessly, even if the end result isn't "clean" or "elegant". The "clean" and "elegant" solutions to these problems are vastly more complex and overengineered.)

I believe I have a problem Nix is designed to solve (reproducible builds) all the time. However, one can work around it with enough pain and suffering on Ubuntu (I can write a shell script to download and build the specific GCC, GHC, rustc and other packages I need and build from source where required), and still find that much easier to distribute to my colleagues, rather than having to teach them to use Nix.

What else is Nix good for? I'd be interested to know.

Nix allows you to abstract over your shell scripts. Like pack those fuckers in a derivation and now people can install them with Nix in a uniform way (and compose them with their own packages) instead of manually shell scripting.

You can even use a single overlay to add a namespace to your company's nixpkgs, which will then allow your colleagues to discover all the versions of all those tools with nix repl

    > pkgs.CJefferson.ghc<TAB>

and boom! All the GHC versions you've worked hard to package across branches and repos etc will be at their fingertips.

As is always the case with FP, composition and abstraction is the big longterm win with Nix. No other comparable tool comes close on those axes.

>They find software repositories and package managers confusing and overengineered.

And that's why big distros have created GUIs (e.g. Ubuntu's software center) that truly hide any technicalities. Nix-GUI, as it's now, will instead be more like Synaptic, it kinda makes life easier but you still require technical knowledge to use it.

This GUI started few months ago so you shouldn't be surprised it's unpolished. Right now it's the Nix configuration with buttons rather text.