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
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 purpose