Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We want to make Nix better

determinate.systems

Post reply on HN
Print view View original

181–190 of 204 posts

Re: We want to make Nix better

#181

Post by kaba0 »

lykahb wrote: post #106

The name Nix is used for the language, package system, and sometimes the whole ecosystem. There is a recent post that tells the difference https://www.haskellforall.com/2022/08/stop-calling-everythin... Knowing functional programming helps but Nix still is a hard language to learn. I have a lot of Haskell experience but the Nix language was very confusing for me. At first I couldn't even tell a variable name from a k…

I believe blaming the language is misguided. The problem is that nixpkgs’ constructs are not well documented, or not yet stable. It would be a problem in any language (you can’t expect someone to feel familiar in a new codebase, and nixpkgs is essentially that).

Re: We want to make Nix better

#182

Post by grumbel »

ghoward wrote: post #111
vdijkbas wrote: post #102

Earlier quoted context omitted.

> This is why Nix is really just a front for bash. For all of its faults, at least bash is Turing-complete. Nix is Turing-complete. This was even sometimes considered a problem because it makes the language too powerful: https://nixos.org/~eelco/talks/guix-feb-2018.pdf

This is news to me, I admit. But if this is true, then people shouldn't say Nix is declarative.

This shouldn't really come as a surprise, any reasonably powerful language will end up Turing complete sooner or later, it's pretty difficult to avoid. Nix specifically doesn't even hide it, it has plain old function and recursion as primitives.

What makes it declarative is the lack of side effects and laziness.

Re: We want to make Nix better

#183

Post by rgoulter »

sph wrote: post #165
SAI_Peregrinus wrote: post #81

Earlier quoted context omitted.

Just tried it, it does work. Not in the `--help` though.

This subthread is exactly why NixOS is getting much traction outside of enthusiasts and people with a lot of patience.

Missing a 'not', I think?

I think the idea that Nix is difficult to get started with, and undocumented, isn't a surprise to the community. -- These were some of the most repeated points in the community survey. And the topic of the submitted post.

That said, I do think Nix has seen a lot of growth over the last year, and I see fewer "nix is so easy" comments.

Re: We want to make Nix better

#185

Post by grumbel »

AprilArcus wrote: post #136

Just let me a pin a single package to a version number, for the love of God.

You can do that with something like this:

    pkgs.yourpackage.overrideAttrs { prev: {
       src = fetchurl {
          url = "...";
          sha256 = "...";
       };
    }}
Bit annoying that you have to specific the full URL instead of just the 'version' number, but it'll work.

With flakes you can just add a 'ref' or 'rev' to the URL:

    nix run "github:juser/software?ref=v0.4.1"
If you want to override a package dependency across 'override'.

Re: We want to make Nix better

#187

Post by kaba0 »

tazjin wrote: post #63
tadfisher wrote: post #31

Earlier quoted context omitted.

I might suggest making a typed superset of Nix, basically adding record types and function signatures. That in itself would be a huge boon for tooling and interacting with nixpkgs. nixpkgs describes a huge and varied meta-API for derivations in various build ecosystems, which makes it hard to use because you ultimately need to dive into source code.

Some community members have looked into this quite a bit, and personally I have come to the conclusion that types don't really give that much benefit to Nix (and I say this as a Rust & Haskell developer). Nix expressions are almost always[2] short-lived snippets that evaluate to a data structure, not long-running programs where the distinction between "static analysis time" and runtime is extremely relevant. In fact,…

I am originally opposed to blaming the Nix language, but now that I read your comment and thought a bit more about it, Clojure’s spec might be a much better tool than types. It would solve the readable error messages problem quite well and is flexible enough to accommodate any usage like parameter passing.

Re: We want to make Nix better

#188

Post by rssoconnor »

WastingMyTime89 wrote: post #167
rssoconnor wrote: post #61

Earlier quoted context omitted.

> To seriously answer the question: is the Nix language required for the Nix packaging system to exist? Laziness is required, to some degree, but can the next iteration provide an on-ramp which doesn't involve learning a new lang and paradigm? Guix folks sure think so. I'd love to hear from someone deeply familiar with Nix and Guix about laziness. I'm deeply familiar with Nix and I've concluded that lazy semantics is…

> I don't need to topologically sort the evaluation of the various inter-dependencies of my configuration. So long as there exists an evaluation order, laziness finds it. That’s not a property of laziness but of how Nix evaluates configurations. I think people overvalue what laziness brings them because they attribute to it things which could be done equally well with an eager language.

There is nothing special about how Nix evaluate system configurations that is any different from how Nix evaluates any other expression.

Being able to write

     let usercfg = { username = "nix-user";
                     homedir = "/home/" + usercfg.username;
                   };
     in usercfg
is nearly a hallmark of non-strict semantics, which is achieved by lazy evaluation.

Strict languages can simulate these non-strict semantics by using functions of no parameters to delay evaluation, but you lose the efficiency that comes from the memoization of record fields that you get with lazy evaluation.

P.S. The above would perhaps be more likely be written as

    rec { username = "nix-user"; homedir = "/home/" + username; }
but when specifying larger configurations composed of multiple nested records with wide cross-cutting inter-dependencies, "rec" doesn't really cut it as "rec" works best with extremely local inter-dependencies.

Re: We want to make Nix better

#189

Post by grumbel »

xyzzy_plugh wrote: post #156
Bolkan wrote: post #140

Earlier quoted context omitted.

What nix needs more than anything is a centralized repository containing recipes for running all the different kinds of programs, as nic files. ie a dockerhub alternative.

nixpkgs?

Something a little more compact would be welcome. There is:

    nix flake show templates
But the examples in there are a bit out of date and don't necessarily reflect real world usage and are lacking in comments (e.g. still using defaultPackage, not using flake-utils, etc.).

Re: We want to make Nix better

#190

Post by sph »

rgoulter wrote: post #183
sph wrote: post #165

Earlier quoted context omitted.

This subthread is exactly why NixOS is getting much traction outside of enthusiasts and people with a lot of patience.

Missing a 'not', I think? I think the idea that Nix is difficult to get started with, and undocumented, isn't a surprise to the community. -- These were some of the most repeated points in the community survey. And the topic of the submitted post. That said, I do think Nix has seen a lot of growth over the last year, and I see fewer "nix is so easy" comments.

I've been on the sidelines for a while, as I keep hearing that NixOS devs are focusing on the documentation for years now... but to be honest I'm not seeing it yet. Documentation was the thing that turned me off it 4 years ago, and I'm a bit sad to see it's still a big problem even if I keep hearing it's being actively worked on.
Post reply on HN