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);
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”.
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.
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.
Anti Commercial-AI license
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 vianix profilebeing 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.
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.anythingor whatever else there is serving a similar purposeIt’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”.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.
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
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.