Nix and NixOS are in something like the state git was in before GitHub: the fundamental idea is based on more serious computer science than the status quo (SVN, Docker), the plumbing still has some issues but isn’t worse, and the porcelain and docs are just not there for mainstream adoption.
I think that might have changed with the release of flox: https://flox.dev, it’s basically seamless (and that’s not surprising coming from DE Shaw).
Nix doesn’t really make sense without flakes and nix-command, those things are documented as experimental and defaulted off. The documentation story is getting better, but it’s not there. nixlang is pretty cool once you learn it well, but it’s never going to be an acceptable barrier to entry at the mainstream. It’s not really the package manager it’s advertised as, nix-env -iA foo is basically never what you want. It’s completely unsurprising that it’s still a secret weapon of companies with an appetite for bleeding-edge shit that requires in-house expertise.
flox addresses all of this for the “try it out and immediately have a better time” barrier.
Nix/NixOS or something like it is going to send Docker to the same dustbin Subversion is in now, but that’s not going to happen until it has the GitHub moment, and then it’ll happen all at once.
Most of the complaints with Nix in this thread are technically false, but eminently understandable and more importantly (repeat after me Nix folks): it’s never the users fault.
I’m aware that I’m part of a shrinking cohort who ever knew a world without git/GitHub, so I know this probably sounds crazy to a large part of the readership, but listen to Linus explaining to a room full of people who passed the early Google hiring bar why they should care about a tool they feel is too complicated for them:
Ron from flox.dev here, the note brought a lot of smiles across the team. We've been working on this for a while now and would love to hear if there is anything we can prioritize or do to keep making it better.
I’m glad to hear it! I’ve been grappling with how to package something I’m calling “HYPER // MODERN” (which I can talk about if you’re curious) and we’re pretty locked-in on flox at this point, it had been a combination of flakes and Homebrew and flox is just a better time.
If you drop me an email at b7r6@b7r6.net (I also just joined your slack) I’d love to give my feedback on this or that nitpick.
But overall, well done friends, very very nice stuff.
I believe for a developer tool to success, for the most common thing to do there has to be at least three ways an engineer may misuse your tool and still get it "done" (by leaving non-obvious tech debts behind).
This is true for git, but not so true yet for Nix, so I'm not sure a GitHub-like moment helps.
In a full-metal-jacket NixOS setting it’s bloody hard to bash (no pun intended) your way through to the next screen by leaving behind tech debt (Python comes to mind, I made the mistake of trying to use Nix to manage Python once, never again).
But anywhere else you just brew/apt/rpm install whatever and nix develop —impure, which is easier than most intermediate git stuff and plenty of beginner stuff. git and Nix are almost the same data structure if you start poking around in .git or /nix/store, I might not understand what you mean without examples.
But all my guesses about what you might mean are addressed well by flox.
I think that might have changed with the release of flox: https://flox.dev, it’s basically seamless (and that’s not surprising coming from DE Shaw).
Nix doesn’t really make sense without flakes and nix-command, those things are documented as experimental and defaulted off. The documentation story is getting better, but it’s not there. nixlang is pretty cool once you learn it well, but it’s never going to be an acceptable barrier to entry at the mainstream. It’s not really the package manager it’s advertised as, nix-env -iA foo is basically never what you want. It’s completely unsurprising that it’s still a secret weapon of companies with an appetite for bleeding-edge shit that requires in-house expertise.
flox addresses all of this for the “try it out and immediately have a better time” barrier.
Nix/NixOS or something like it is going to send Docker to the same dustbin Subversion is in now, but that’s not going to happen until it has the GitHub moment, and then it’ll happen all at once.
Most of the complaints with Nix in this thread are technically false, but eminently understandable and more importantly (repeat after me Nix folks): it’s never the users fault.
I’m aware that I’m part of a shrinking cohort who ever knew a world without git/GitHub, so I know this probably sounds crazy to a large part of the readership, but listen to Linus explaining to a room full of people who passed the early Google hiring bar why they should care about a tool they feel is too complicated for them:
https://youtu.be/MjIPv8a0hU8?si=QC0UnHXRdMpp2tI4