#1 things holding back Nix adoption is piss poor documentation
The docs are bad because there is this massive split between flakes and nonflakes , where flakes are considered “unstable” and “experimental” but a ton of people use them. The official docs, due to flakes being experimental, can’t really touch on that topic at all, and the unofficial docs will mostly be flakes only. And some things can only be done via flakes or only via channels, so that furthers the issue.
There was another discourse post about it, and it was agreed that the nix team just needs to choose something, as the problem is the split and indecisivice, rather than flakss or channels (old way) being uniquely bad.
where Nix “3rd party” tooling shines is in documentation
Determinate systems nix ships with flakes enabled by default. Official nix does not. This means thay determinate nix has a much easier time documenting their product as they exclusively use flakes.
The problem and potential conflict of interest documented in that thread, is that many of the determinate systems employees are big nix contributors with much power over nix official — including Eelco Dostra, the inventor of nix and the creator of flakes. Despite clearly doing recent work with flakes, and clearly contributing to making flakes the “default” in determinate nix, very little effort has been put into making flakes official by these same contributors.
The fear is that nix official is being intentionally kept bad, in order to push the product of determinate systems nix.
i worked in Android development for years. i used Kotlin and Jetpack Compose in alpha. their docs weren’t perfect but they existed. in my experience good documentation evolves with the project and isn’t tacked on as an afterthought.
otherwise i get you point and really don’t know enough about the drama to pick a side. i just want my software to work 🤷♂️
ETA: honestly documentation as a first class primitive in Nix is a selling point. if only that consistency could be applied to high level docs
The docs are bad because there is this massive split between flakes and nonflakes , where flakes are considered “unstable” and “experimental” but a ton of people use them. The official docs, due to flakes being experimental, can’t really touch on that topic at all, and the unofficial docs will mostly be flakes only. And some things can only be done via flakes or only via channels, so that furthers the issue.
There was another discourse post about it, and it was agreed that the nix team just needs to choose something, as the problem is the split and indecisivice, rather than flakss or channels (old way) being uniquely bad.
Determinate systems nix ships with flakes enabled by default. Official nix does not. This means thay determinate nix has a much easier time documenting their product as they exclusively use flakes.
The problem and potential conflict of interest documented in that thread, is that many of the determinate systems employees are big nix contributors with much power over nix official — including Eelco Dostra, the inventor of nix and the creator of flakes. Despite clearly doing recent work with flakes, and clearly contributing to making flakes the “default” in determinate nix, very little effort has been put into making flakes official by these same contributors.
The fear is that nix official is being intentionally kept bad, in order to push the product of determinate systems nix.
Part of the reason why a lot of people are moving to projects like Lix, including increasing use amongst core contributors
i worked in Android development for years. i used Kotlin and Jetpack Compose in alpha. their docs weren’t perfect but they existed. in my experience good documentation evolves with the project and isn’t tacked on as an afterthought.
otherwise i get you point and really don’t know enough about the drama to pick a side. i just want my software to work 🤷♂️
ETA: honestly documentation as a first class primitive in Nix is a selling point. if only that consistency could be applied to high level docs