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

91–100 of 204 posts

Re: We want to make Nix better

#91

Post by Daegalus »

anderspitman wrote: post #87

For the first time in about 8 years an Arch update rendered my OS unbootable last week. I'd had graphics issues once or twice but this time it just hung in systemd somewhere. Still don't know what happened. Rolled all packages back about a month and that worked, but I'll need to update eventually. I'm considering Nix but don't like the custom language. I wish Guix were. more popular and less extreme on the freedom si…

you can try something like Kinoite or Silverblue from fedora.

you can also manage tools with asdf if it makes it easier.

I personally run Fedora + Flatpaks + asdf and it covers everything, and is stable, up to date, and has a new release every 6 months. it feels midway between a rolling release and. apoint release

Re: We want to make Nix better

#92

Post by jcynix »

anderspitman wrote: post #87

For the first time in about 8 years an Arch update rendered my OS unbootable last week. I'd had graphics issues once or twice but this time it just hung in systemd somewhere. Still don't know what happened. Rolled all packages back about a month and that worked, but I'll need to update eventually. I'm considering Nix but don't like the custom language. I wish Guix were. more popular and less extreme on the freedom si…

I just started to experiment with EndeavourOS, a prepackaged version of Arch. Looks nice so far.

https://endeavouros.com/about-us/

Re: We want to make Nix better

#93

Post by tinco »

rgoulter wrote: post #21
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…

> they haven't been able to focus on the UX. I also feel like folks for whom Haskell is comfortable may not realize just how absurd it feels to everyone else. The majority of communication I've seen from Nix maintainers over the last few months has been about exactly this. The submitted post is about exactly that while Nix powerful, they want more people to be able to use it without having to pay a steep penalty to l…

It also doesn't have anything to do with Haskell or it looking somewhat like Haskell. I'm very comfortable in Haskell, and Nix looks awful to me. It's not that it's functional or it's declarative, it's that it's badly designed and not intuitive, making it hard to remember and therefore awkward to code in.

Re: We want to make Nix better

#94

Post by qbasic_forever »

tikhonj wrote: post #85
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…

Having used Nix a bunch, the system has been hard to use and learn in exactly the same ways that messy legacy codebases I've worked with have been hard—which makes sense since Nixpkgs is an absolutely massive codebase that's evolved over the years with very distributed development. People latch onto the Nix language and the paradigm because that's the most tangible difference but, everything else held equal, Nix + Ni…

Yeah IMHO nix just needs someone like Brian Kernighan to sit down and write the definitive book about it and its internals. Something that clearly explains the practical and theoretical uses of nix and nixpkgs.

Nix pills, the official manual, etc. aren't really there yet--they talk about all kinds of paradigms that might (?) be going away like nix-env and its ilk. It's just extremely painful to track down the current best practice and way to do things in nix--you're bouncing off all kinds of docs and finding multiple conflicting or out of date ways to do things. Someone needs to give folks a slim book about nix flakes and the flakes way of doing things, the nix language, and a tour of nixpkgs, and IMHO there will be a lot more people using it.

Re: We want to make Nix better

#95

Post by nonsequitur »

gavinhoward wrote: post #66

Disclaimer: I'm working on a build system that will eventually do what Nix does but make it much easier to use. If they do manage to create a system where Nix is hidden, and end users never have to directly touch it, I think this could work and make my work never see the light of day. But I have my doubts that they will be able to do that, and it boils down to one simple reason: declarative is not powerful enough. Do…

Nix is turing complete (it can implement the Lambda Calculus), even conveniently so.

Re: We want to make Nix better

#96

Post by theptip »

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…

Having just done some prototyping with Nix, this list is spot on in enumerating the pain points I hit.

I think most of the docs problems could be solved with the meta-strategy of “deeply understand all the things the Rust ecosystem got right with docs, discovery, and general pedagogical structure, and replicate that”. Actually have a canonical set of docs. Link liberally between packafes and stdlib. Figure out typing so you can get those hints and links in your IDE. Fix the package docs so they actually tell you what functions the packages export, instead of relying on the wiki for instructions. Etc.

Basically, pay a couple excellent docs people for a few years.

I found the language a bit weird but not terrible to learn. But if it’s possible to build some porcelain for common usecases that skips there need to grok the language, that could be quite transformative. I do wonder if the “dev env/packaging” use-case might be simpler than the “run and configure a whole OS” usecase.

Re: We want to make Nix better

#97

Post by dial9-1 »

techdragon wrote: post #35
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…

Point 4 is what lost me when I tried using NixOS for a machine I explicitly wanted as reproducible as possible. I needed to get a bunch of stuff working, then freeze/bundle/lock the useland as a documented working state I could rebuild later if anything went wrong. When documented examples began steering me towards the still experimental nix flakes and using the sorts of with ever more flags required commands, I bail…

flakes are anything but experimental at this point, they've been out for many years and I pretty much use them for everything. you don't have to type those flags if you add them to the configuration file

Re: We want to make Nix better

#98

Post by qbasic_forever »

beermonster wrote: post #83

Is it Nix or NixOS?

Both exist. Nix is a functional language for describing how software is built. Nix is also a package manager of sorts that installs and manages software built with its language. NixOS is an operating system that is described entirely by a nix language configuration file that builds a bootable linux-based OS using nix language packages.

Re: We want to make Nix better

#99

Post by barkingcat »

qbasic_forever wrote: post #94
tikhonj wrote: post #85

Earlier quoted context omitted.

Having used Nix a bunch, the system has been hard to use and learn in exactly the same ways that messy legacy codebases I've worked with have been hard—which makes sense since Nixpkgs is an absolutely massive codebase that's evolved over the years with very distributed development. People latch onto the Nix language and the paradigm because that's the most tangible difference but, everything else held equal, Nix + Ni…

Yeah IMHO nix just needs someone like Brian Kernighan to sit down and write the definitive book about it and its internals. Something that clearly explains the practical and theoretical uses of nix and nixpkgs. Nix pills, the official manual, etc. aren't really there yet--they talk about all kinds of paradigms that might (?) be going away like nix-env and its ilk. It's just extremely painful to track down the current…

I dislike that the way nix is onboarded for new folks is nix-env, and then for the next documentation to say: nix-env is bad don't use it.

If it was bad why show it to me at all?

Re: We want to make Nix better

#100

Post by ridiculous_fish »

ParetoOptimal wrote: post #13
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 install process was simpler before recent OSX updates. > 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. Since you'd already installed it, wouldn't trying it in some capacity before uninstalling it have made sense? > What is the reason for all this machinery Enforcing reproducibili…

> Since you'd already installed it, wouldn't trying it in some capacity before uninstalling it have made sense?

Fair observation. I installed nix as a prerequisite for DevBox, discussed here https://news.ycombinator.com/item?id=32600821 . I thought DevBox sounded really cool (and still do!), but the Quickstart took frustratingly long, and ended up not working. Faced with the prospect of debugging it, I opted to cut my losses and uninstall it instead.

That said I'm very much open to trying nix again in the future. Also I want to acknowledge how much effort went into getting /nix to work on the Mac; it appears that was a heavy lift indeed.

Post reply on HN