"The Purely Functional Package Manager" - what does that mean and why do I want that instead of ruby gems, php composer, jar files, maven, leinegen, nugget, etc?
"Nix is a powerful package manager for Linux and other Unix systems that makes package management reliable and reproducible." - What if I want Windows? (serious question)
I could go on, but none of what is on the landing page explains why Nix should replace ruby gems, php composer, or any other package manager. It's like saying you are mad at the 13 other standards so you create the 14th standard for people to standardize around. Now you have 14 different standards.
By "Purely functional package manager", it's implying "referential transparency" of package definitions/build processes - meaning that given the same inputs to the package definition each time, it should always produce the same result. (OK, in practice this doesn't work exactly as we want it because of various things out of our control, such as timestamps which get inserted into binaries - but there's ongoing work to overcome these deficiencies so we can create binary-exact replicas, reliably[1]). For now, Nix is only referentially transparent at the source level - it requires that packages are built from the same source code that was specified in the original package definition.
The reason we want referential transparency for packages is to make them reliable - so that another person building your package gets the same result you did, and something like an environment variable, missing packages, or different native package on his system doesn't cause the software to break, or simply fail to build. If you've ever tried to build some software and configure or make has returned some cryptic error you end up googling - this is exactly what Nix solves.
On "What about Windows?" It's a serious question, but the serious answer is that nobody is interested - if Windows users really wanted it, they'd build it, and so far, they're two decades behind even the most basic kind of package management offered by Debian. The best Windows has so far is nuget, which is language specific, and also pretty miserable at actually solving the package management problem - it's a convenient hack.
A more interesting project on Windows is CoApp, although I'm not sure if it's still in development. The idea behind CoApp was to create a Visual Studio project file for common open source software and test them - such that Windows users will not be required to install mingw/msys/cygwin to provide some basic functions to their machines.
Nobody is suggesting that Nix should replace all the package managers, but the idea behind it is probably more valuable than others going into the future where complexity will continue to increase, and traditional package managers have stagnated in solving our dependency problems.
The issue of standards and "one to rule them all" isn't really what nix aims for either - it's in fact, completely incompatible with other PMs by nature - because it requires that dependencies are exact, and other PMs simply cannot provide anything of that nature - they only produce "approximate" packages.
> On "What about Windows?" It's a serious question, but the serious answer is that nobody is interested
I personally am interested. By what you and a lot of people here said Nix's Windows support is not great (and no, support through Cygwin does not count). So Nix is already ruled out for me.
I am willing to bet that getting Nix to work reliably on Windows would have taken far longer than Babel.
I'm not sure Nix will be very effective on a proprietary platform where updates can be forced on users, where you can't necessarily roll back, because it's out of your control - and where the licensee can forbid you from distributing old versions.
Trying to make Nix work on windows would require making up "psuedo-packages" for components of windows, where some hash of the binaries is used to identify them - one problem is we can't guarantee that components in windows can even have an identity which is common between installs - there could be a significant amount of unique configuration embedded into each install of the OS, which would give unique hashes, making it ineffective to even bother trying to make package trees where dependencies are exact - every user would need to maintain their own tree.
If anything like Nix were to come into windows, it would probably need to come out of Microsoft to be effective - they'd need to acknowledge the merits of Nix and decide to push updates through a similar model.
CoApp was of interest because its author was in Microsoft, and had potential to make an impact on the way software is delivered on Windows - it used separate shared libraries for each dependency without dumping them into project folders (by making effective use of the SxS technology in windows). It also required packages to be signed, which would've provided some of what is necessary in a model like Nix's, and in CoApp, each package is maintained in git, in a separate repository from the original projects. It looks like CoApp is still being worked on, although there's little activity - Nuget basically pushed this project to be stillborn, because Nuget provided an immediately convenient solution to the woes of Windows developers, without actually solving package management - the rest of Microsoft jumped on it and CoApp was ignored.
Perhaps the downside of CoApp is the requirement to support Visual Studio, and to not acknowledge the existence of mingw/msys, which are really a requirement for building many projects, and the effort to port these builds into VS is non-trivial. I agree that cygwin is not a solution, it shouldn't be considered as such as it's more like the windows equivalent of WINE. Mingw/msys suffers from nearly all the same woes as the rest of windows, although it now has it's own "PM" (mingw-get), which is an improvement over the way things were done before then, mingw-get isn't a very sophisticated PM, more like a specialized downloader.
This goes against what i just said above, but I think any potential solution on Windows needs to be liberated from Microsoft (and MS specific toolchains) - that is, a solution built around mingw and msys, whereby the mingw base packages become the bootstrap packages for an immutable model, and where those packages can reference Windows components with some alternative means to give them identities other than hashing of binaries - for example, the PM could provide some way to override the requirement of hashes for dependencies, granting that special permission only to mingw packages. The rest of user-land software would be built with mingw.
Of course there is conflict here on building with VS versus mingw - the binaries produced by each aren't really compatible at all, so the use of both would require a dual build system. There's something out there like this - the KDEwin project, which has packages for both toolchains - however, there is still significant work needed to improve the state of KDE on windows, and the PM itself.
Nobody is really suggesting that we don't use Babel, or that Nix is going to replace it overnight - you're absolutely right that getting something like Nix on Windows will take monumental effort, but we're sharing ideas for more long-term solutions to packaging problems, which continue to get more complex, and tools like Babel don't actually do much to solve that growing complexity.
"The Purely Functional Package Manager" - what does that mean and why do I want that instead of ruby gems, php composer, jar files, maven, leinegen, nugget, etc?
"Nix is a powerful package manager for Linux and other Unix systems that makes package management reliable and reproducible." - What if I want Windows? (serious question)
I could go on, but none of what is on the landing page explains why Nix should replace ruby gems, php composer, or any other package manager. It's like saying you are mad at the 13 other standards so you create the 14th standard for people to standardize around. Now you have 14 different standards.