Nix needs a typed language, better CLI interface, better documentation, a distributed cache, to to get rid of the monorepo / single source of control, to support different builders (aka not just bash), and have a less toxic community.
For nix to be used by normal, non technical users, it must have a GUI. That is not optional.
Nix could be great for a lot of things, but it's not the only solution and won't be the last.
Nix is typed: there are strings, paths, lists, attrsets, etc;
Not sure what's wrong with CLI, as I don't really use it except nix flake update (although I remember updating stuff installed via nix profile being a bit cumbersome, but it's not exactly a good practice to use it this way);
Good point with cache, although stuff outside of nixpkgs sometimes provides their own caches which are trivial to enable;
Nobody forces you to use github:nixos/nixpkgs, it's just a regular input. Ppl quite often have their own forks. It's also trivial to use stuff from outside nixpkgs (also just another input);
There are different builders (e.g. buildGoModule);
Idk where you've found toxic community, my interactions have been pretty nice so far (mostly matrix rooms);
GUI is optional, just like for all the other package managers. And it exists: https://github.com/snowfallorg/nix-software-center
Perfectly agreed with nix not (yet 🙃) being the best thing that exists, tho, albeit due to different reasons. For example, it's a PITA to debug, and the error messages are sometimes unhelpful.
Nix is typed: there are strings, paths, lists, attrsets, etc;
Those aren't types as far as programming language theory is concerned, they're (using Rust terminology) variants of enums.
It's not really unityped ("dynamically typed") either, though, but it's a rather small wibble: Include paths aren't normal values, they must be statically evaluable. AFAIU that was some prescience regarding enabling future addition of separate compilation and maybe even proper typing.
Otherwise the language is just the untyped lambda calculus with a couple of primitive data types thrown in, just like lisp, scheme, or also lua or js (if you squint a bit), what makes it different is that it's lazy and pure. Heck, it's a language where you have to write down the y combinator (which wouldn't work in typed lambda calculi) to do loops what else but the untyped lambda calculus is it supposed to be.
That all said, nickel exists. The whole CLI situation as well the documentation is a mess because practically everyone is using flakes even though it's not an official feature (yet). And, of course, nixpkgs is nowhere close to having been ported to flakes, AFAIK we're not even close to starting. Personally I think it should be done at the same time as a move towards nickel as not to do it twice but that requires nickel to actually get integrated into nix (as in the package manager).
tl;dr: NixOS is still very much in its "move fast and break the docs and all your habits" kind of phase. What it has going for itself, of course, is that "break things" doesn't happen while that's happening.
Fair enough, I guess. Although I'm not sure I immediately see how nickel is better. Off the top of my head, typing would mostly matter in stuff like options, where we have type checks (ish) already, unless using types.anything or whatever else there is serving a similar purpose
It's mostly useful for all kinds of reusable code aka "why do I have to run the code before nix can tell me that I missed an argument to fetchFromGithub".
https://snowflakeos.org/ - this project is focused on building an easier version of nixos including a GUI software store based on gnome software.
edit:ooops I meant to respond to @[email protected] here
I agree, the CLI is good enough. Thanks for the note about the GUI package manager! I hadn't heard about that.
I also second the positive interactions. Mine have been almost exclusively positive. I've come across a few no effort "RTFM, idiot" attitudes but it's rarer on Nix forums and repos than I've seen elsewhere.
The CLI is good, but it's need to be stabilized. The CLI you're describing is the version 3 CLI, but there are still use-cases where you need to use the version 2 CLI.
As it stands now, I don't think nix wants "regular users"; rather it wants user/contributors.
Nix is weird and confusing, and I say that as a self holster and student of computer science. Nix is a weird side thing.
I've got it working a couple of times. In my opinion they need to fix documentation, make flakes an officially supported thing and take it out of beta that it's been in for years so that documentation can be further created, and the installer should work on a majority of devices out of the box.
My laptop was the worse experience. I just wanted KDE and Firefox. I don't use it for much. But, KDE wouldn't load so I had to go into CLI and edit the configuration.nix and change some stuff to get it to work. It's a thinkpad that has official support for Linux. So, it was specifically a nix driver issue. I just installed Arch again and went on like normal. I would love to trust it with a server. But, I just can't.
The headline felt a little weird, but turns out this wasn't written by Eelco. I thought how can they have found nix in 2016 if they've created it to begin with lol
Either way, I've switched all by one of my machines to Nix now, including my Darwin laptop, and it's honestly been pretty damn good.
Aside from the huge learning curve, and a pretty depressing turnover rate for an occasional package update request, especially when it comes to home-manager.
The ability to have a flake structure, that you can push to git, and then re-use on all of your systems, is huge.
So I’m running Debian. Say you want to use nix on it.
Is installing a package as simple as $ nix install vscode ? And would it “just work”?
Might give it a try if so.
Is installing a package as simple as $ nix install vscode ? And would it “just work”?
You fool. You absolute buffoon. You're doing it wrong. That's the wrong command, and even if it was the right command, this method could cause issues down the road. It goes against the declarative philosophy of nix. You're supposed to refer to packages by their attribute, rather than name. If you launch the installed app that way, it won't have any hardware accererated graphics becuase hardware accelerated graphics are impure, don't you know this?
You need to read the nonexistent documentation to find all of this out, and then select a declarative solution, like home manager or nix-shell or nix develop, to install software, and nixgl to get hardware accelerated graphics for nix packages on non nix systems.
(/s (ish) over)
Yeah. Nix has some issues. If you just want more packages available, I would recommend distrobox.
It's a very powerful tool, and I use nix to manage all of my development environments, but it has some severe limitations that only have hacky workarounds. I could not get hardware accelerated nix packages to have a working dekstop entry. So instead, I have to type nixGLIntel gzdoom in my terminal when I want to play doom.
In addition to that, the documentation is very poor.
The other comments in this thread elaborate on these, and a few other issues.
Oh. I see. Thank you.
I mean, yeah, it's nix profile install nixpkgs#vscode and it should kinda work. Although to run it, you might have to also do nix profile install github:nix-community/nixgl --impure and then run vscode as nixGL code because of video driver awfulness.
Oof
Unfortunately, Determinate’s installer doesn’t work on my new Macbook ☹️