Nix is indeed a great idea. I do hope that idea’s time has come. But, oh, man, that config syntax. I’d love to see some alternative, human-friendlier interface; am thinking here of how Elixir really induced a significant pickup in usage of the BEAM owing largely to being perceived as friendlier to newcomers than Erlang.
Nix (the language, not to be confused with NixOS, the operating system) is not that hard to pickup, if you already know a programming language or two. Read through about the syntax and you'll get the gist in a couple of hours, and you basically know it inside out if you spend a day or two reading and experimenting with it. You just need to spend the time to understand it, and it's no longer a hurdle.
What I think really stops NixOS from gaining mainstream popularity (eh, mainstream like in the Linux ecosystem, not mainstream-mainstream) is the inability of just downloading binaries and running them, when you have to. It's a huge hurdle to try to figure out the right incarnation to set the lib paths correctly for the binaries but woops, it's actually using something else and now you need to do some other hacky thing. nix-autobahn et al exists but are also hacky and sometimes outright doesn't work, and then you're basically lost, unless you can rebuild the binary yourself, which unless it's free/open source software, you're unlikely to be able to do.
This, I think is the real reason people are avoiding to adopt it, because there is no easy solution to this problem, unlike the problem of syntax which can be solved by simply learning it.
I would be surprised if there are any binaries that are outright impossible to run under Nix. I spent a weekend getting Xilinx ISE to run in Nix [0], that is a binary behemoth. It uses bubblewrap (already used in Nixpkgs) to setup a bunch of bind mounts so that the binaries see a standard FHS Linux layout.
Yeah, nothing is impossible if you have the time/energy to spend the effort :) I'm not saying there are binaries that are impossible to run, just that some of them are very hard to get running correctly if they have some special setup where the automated tools don't work very well with it. Things like Java programs that are wrapped in a shell-file that gets called from a binary tend to be a huge hassle to get setup correctly, while on other OSes like Arch Linux, you simply run the binary and it works.
Again, not impossible to get them running, just a huge timesink.
> What I think really stops NixOS from gaining mainstream popularity ... is the inability of just downloading binaries and running them
This is THE reason I switched from NixOS back to a mainstream distro (Fedora). However, I still use Nix for my development environments and builds for a lot of projects. I think adoption of Nix itself is more important than NixOS.
Yeah, sometimes you have to rely a lot on context to understand if they're talking about Nix the package manager or Nix the language, but the documentation does mostly do it well by strictly saying things like "Nix package manager", "Nix Expression Language", "Nix Packages collection (Nixpkgs)" and "NixOS Linux distribution" so it's mostly clear, I think.
> Packages are built from Nix expressions, which is a simple functional language
> We provide a large set of Nix expressions containing thousands of existing Unix packages, the Nix Packages collection (Nixpkgs).
> NixOS is based on Nix, a purely functional package management system. Nix stores all packages in isolation from each other under paths
> In NixOS, the entire operating system — the kernel, applications, system packages, configuration files, and so on — is built by the Nix package manager from a description in a purely functional build language
Lastly, the learn page (https://nixos.org/learn.html) links to three different manuals in the bottom, titled "Nix Manual", "Nixpkgs Manual" and "NixOS Manual" respectively.
I'm sure if you find specific places in the manuals/guides/wikis where it's unclear which one is being referred to, they would really appreciate your help in fixing it, or at least pointing out it's not clear. They tend to be really responsive in the IRC channel the times I've talked with Nix people.
> So in some sense the language is a decent filter for people who won't like the inevitable rest anyways.
I'm not saying i'd like to package complex systems with nix/guix, but i certainly would use them more to package my own projects if the ecosystem had better docs and error messages in regards to typing/syntax.
I'm ready to carefully read through a 20 pages manual if that's what it takes, but i personally find the documentation and diagnostics of both projects to be sub-par compared to my expectations (looks really clear on paper, now why doesn't my declaration work?). Granted, i'm not a skilled engineer so maybe i'm not your target audience, but i believe as an amateur programmer/sysadmin i'm part of the target audience to package anything i find useful and/or my own programs.
Yes, we should have better docs! (I think we have a bad mix of authoritative reference and tutorial that fails on both counts.)
But if you want types, I daresay you are already understanding the basics of how the functional language works :). I imagine your problems are less:
wtf is: ((x: x x) (y: y y))
and more:
wtf is stdenv, wtf is mkDerivation, wtf is a setup hook, why are othre build systems hacks on top of the autotools defaults, and not clean alternatives? etc. etc.
Well to be fair i don't understand this syntax. But i guess i should be able to learn it in under one page of docs.
> wtf is stdenv, wtf is mkDerivation, wtf is a setup hook, why are othre build systems hacks on top of the autotools defaults, and not clean alternatives? etc. etc.
But yes my problem is that i don't have a list of standard options and their types so i end up doing copy-pasta of what works in another package and adjust until it works. On a higher level, i've found it harder than expected to turn an existing package declaration from nixOS into a source-provided build file to try and build a specific branch. Or to use an existing NixOS declaration to build a reproducible (and installable) liveUSB as there seems to be various tools doing this job but i couldn't get any of them to build successfully.
I'm interested if you have good learning resources to share!
Is it funny that many people are saying that to which the reply is always "...it is not hard..."
I am going with the "configuration syntax is complex and difficult..." rather than deny the reality of actual people who have set out to use this system.
Would not be the first time developers and fans have disagreed with users. side with the users every time (except when that developer is me)
> I am going with the "configuration syntax is complex and difficult..."
I guess it's by comparison.
Whenever some NodeJS or Python project is mentioned, I've never seen the complaint "NodeJS syntax is too hard" or "Python syntax is too hard".
Nix's syntax itself is not difficult. It's slightly different than other languages, but developers are used to same-thing-different-syntax in different languages.
e.g. in NodeJS, you might have a lambda like: `({ x, y }) => x + y`. In Python, this is `lambda x, y: x + y'. In Nix, this is `{ x, y }: x + y`.
> Whenever some NodeJS or Python project is mentioned, I've never seen the complaint "NodeJS syntax is too hard" or "Python syntax is too hard".
Because their syntax is used for more than just configuration (if it's used for configuration). These are full programming languages that a lot of people know and understand.
Nix on the other hand is a DSL that is used in exactly one place: nix configuration. So I think it's fair to complain about nix-as-a-language and its syntax when the only place you will ever encounter it is nix configuration.
And especially with gems like
--- start quote ---
Attempting to perform division in Nix can lead to some surprises.
nix-repl> 6/3
/home/nix/6/3
What happened? Recall that Nix is not a general purpose language, it's a domain-specific language for writing packages. Integer division isn't actually that useful when writing package expressions. Nix parsed 6/3 as a relative path to the current directory. To get Nix to perform division instead, leave a space after the /. Alternatively, you can use builtins.div.
The programming languages developers use have surprises and inconsistencies like this when you compare between them. It seems awfully pessimistic to think Nix is too hard to use for things like that. (Although I never really understood people who detested Python's whitespace significance, either).
I think it's also a bit impractical. I'd be surprised if anyone refused to use Terraform because they didn't like HCL. (Well, these days there's Pulumi). -- I think Nix's boon to managing packages makes it worth the minor unfamiliarity of a very simple programming language.
I refuse to use Terraform, and Pulumi, and many other things :)
One-off, poorly specified DSLs with no tool support, no debuggability, bad error reporting etc. are a good thing only in theory.
In practice, yes, we often have to use them because there's no other choice. It doesn't mean "oh just get over it, and reap the benefits" is a good argument.
Only Terraform uses a one-off poorly specified DSL.
Pulumi is based on real programming languages. The criticism might be that their libraries/API is poorly specified. But the languages it's based upon are standard with all the tooling one's used to.
In my (rather limited) experience, the poor specification of Pulumi's libraries is almost entirely down to the fact that they are exposing equally poorly specified functionality from cloud providers.
I tried nix (the pm not the os) for a while, and the reward did not match the cost for me. The docs are horrendously confusing to a newcomer, the stack overflow answers make assumptions about concepts you've never heard of, and generally things are never really explained to a degree you feel confident. Nix feels like one of those things where a lot of people copy and paste snippets, because learning the underlying language/ecosystem/OS takes an extraordinary amount of effort.
