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

131–140 of 204 posts

Re: We want to make Nix better

#131

Post by joshka »

rssoconnor wrote: post #61
Jeaye wrote: post #15

Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…

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

> Nix's system of overlays depends on laziness too to provide efficient late-binding familiar from OOP.

As an OOPer, inheritance is one of the things that is generally trotted out as the worst aspect of OO languages. This leads to the mantra "favor composition over inheritance". Much has been written about why and how. But it seems to cause the same pain points that people talk about with respect to laziness in Nix. "Spooky action at a distance" is one of my favorite ways of describing some of these problems.

(I'm not super familiar with Nix, so I could be misreading the points about laziness. Please forgive me if so.)

Re: We want to make Nix better

#132

Post by [deleted] »

tadfisher wrote: post #23
ridiculous_fish wrote: post #4

I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the r…

> What is the reason for all this machinery? > new Unix group This is used for the daemon, so it doesn't run as root and expose your system to Nix build code. > adds a separate APFS volume I think this is required because of macOS security restrictions preventing direct modification of the root directory. The Nix store has to be housed in /nix because all references to runtime dependencies in the store are absolute p…

[deleted]

Re: We want to make Nix better

#133

Post by joshka »

ridiculous_fish wrote: post #4

I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the r…

The meta answer to the question is this info belongs at the non-existent doc - https://nixos.org/manual/nix/stable/installation/macos.html, but no-one has put it there yet.

Re: We want to make Nix better

#134

Post by soraminazuki »

Jeaye wrote: post #15

Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…

There's lots of criticism about the Nix expression language, but it's way overblown IMO. The core language is small. It's essentially just JSON with functions, very similar to Jsonnet. But with Nix, people make too big of a deal out of implementation details like it being lazy, functional, etc. I personally like Nix as a configuration language because it's suitable for complex configurations despite it being small and simple.

There's a case to be made about improving the state of the Nixpkgs APIs though. Stabilizing the APIs and documenting it more thoroughly would dramatically change how people perceive the complexity of Nix. Experienced Nix users grep the Nixpkgs repo to learn about its APIs, but that's far from ideal for newcomers who won't even know where they should look for information.

Still, despite its reputation, Nix lowers the bar for software packaging. Package definitions tend to be more concise, customizable, and reusable than the competition. Nixpkgs contains many useful utilities for packaging and there's an abundance of real world examples contained in a single repo. I also frequently work with RPM, but Nix is much easier in comparison.

Re: We want to make Nix better

#135

Post by fancyfish »

oxff wrote: post #80

Make the documentation up to the modern standards. If I have to open a single random blog or Github repository to find out what to do and piece it together like a puzzle - it is impossible to adapt at organizational scale. It is also complex enough to require a modern Language Server.

This has been my experience also. I finished the Nix Pills, and got some personal Python/Haskell projects built using nixpkgs by following the nixpkgs language-specific documentation, but anything off the beaten path is going to involve lots of blog posts and clicking through source code. For example in the Haskell world there are so many blog posts that go in different directions from the nixpkgs docs, using flakes, haskell.nix, etc.

We adopted it in an organization of ~100 engineers, and the only way it’s been possible is having a full-time Nix team writing custom Nix functions specific for our environment and projects. That team also does “Nix help desk” work for one-off questions.

Once it works, it does a great job of hermetic builds, easy Docker images, easy to add cross-repo dependencies mixing C++/Python etc. But there are too many rough edges I can’t recommend it in the general case over Dockerfiles, Bazel or language-specific tooling, Cmake, etc. Pick something simpler, ideally whatever is popular for your language.

Re: We want to make Nix better

#137

Post by rgoulter »

wizwit999 wrote: post #78
rgoulter wrote: post #16

I agree with the preamble and the "our mission" stuff. I wish them success at bringing the benefits of nix to more users, but without it being limited to enthusiasts, and people who can afford to deal with rough edges. The "external dependencies" thing shows how Nix can be a tough sell to those who don't click with it. I'd say that the other solutions are: - a README which has a bunch of "apt-get install" commands yo…

How about Bazel, doesn't it solve the same issues?

Both Bazel and Nix have some powerful features to them. (Though, oddly, they don't quite mix).

I think they both also have downsides where, if your software does things in ways they don't like, it's difficult to use them. -- And, your team is going to have a tough time using the tool without sufficient expertise.

As I understand it, Bazel's emphasis is more about compilation, where the big win is building projects where you've got a team big enough (& a project complex enough) that dealing with Bazel saves more time than it costs.

Whereas with Nix.. I think one good use case is "declare & lock the dependencies for this toy project", which then allows picking the project up without having to update your code following updates to the system package manager.

Re: We want to make Nix better

#138

Post by soraminazuki »

pseudalopex wrote: post #129
lilyball wrote: post #128

Earlier quoted context omitted.

Other package managers are okay with requiring sudo because they install stuff globally. Nix doesn't have that restriction, you can use it for local stuff, temporary shell environments, etc. So you need non-admin users to be able to use it too, and even admin users need to be able to use it without using sudo. For example, when entering a nix shell, you don't want the shell to run as root. Or when using direnv. Or ju…

Nix isn't the only package manager for home directories or source packages. Working in a home directory doesn't require sudo or a daemon. sudo doesn't mean run everything as root.

You missed the crucial point:

> So you need non-admin users to be able to use it too

The build daemon and the user are used for privilege separation. The separation goes both ways. Users can't write directly to /nix/store and Nix can't write outside of /nix/store during build.

If anything, it's there to make things less invasive. It's nothing like the Docker daemon, which is a proxy for root.

Additionally, the daemon doesn't do anything unless users request that a package be built.

Re: We want to make Nix better

#139

Post by Bolkan »

Jeaye wrote: post #15

Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…

> Everything should be made as simple as possible, but not simpler

Re: We want to make Nix better

#140

Post by Bolkan »

Jeaye wrote: post #15

Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…

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.
Post reply on HN