Live data from Hacker News

We want to make Nix better

determinate.systems

171–180 of 204 posts

Re: We want to make Nix better

#171

Earlier quoted context omitted.

But, since the files were under /nix, if you put them under /opt, then you wouldn't be able to make use of the compilation caches for /nix. Until a very short time ago there was no binary cache for Apple Silicon Macs.

There are for anything you run as x86_64 (using Rosetta). It's also important if you're cross-compiling anything.

Sure. But I think 90% of the Nix on Apple Silicon users does not compare about cross-compiling or running x86_64 binaries with Nix. So, everyone is worse off for supporting minor use cases.

Re: We want to make Nix better

#172

Earlier quoted context omitted.

The Nix store has to be housed in /nix because all references to runtime dependencies in the store are absolute paths in /nix, This is true, but in some sense Nix on Apple Silicon was a missed opportunity. It started as a blank slate (fresh binary cache) and it would've been a good opportunity to move the store to a writable path like /opt/nix . This would have solved the whole dance needed with volumes and synthetic…

> It started as a blank slate (fresh binary cache) and it would've been a good opportunity to move the store to a writable path like /opt/nix. That breaks caching cross-compiled outputs and x86_64 outputs, which do still run on Apple Silicon.

Which most users don’t really care about. I think it’s optimizing for the wrong use cases.

This is the main reason why I don’t use Nix on the Mac anymore, I just don’t want the pile of hacks that is necessary on my system. And I am a former nixpkgs contributor. Many people will just shrug and install Homebrew.

Re: We want to make Nix better

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

> People rarely jump I'd just like to take a moment to reiterate that object-oriented programming is a mistake produced by cargo-culting half a dozen different styles used by competent programmers (including the devolpers of smalltalk and its relatives, from which OOP appropiated its name), and that Java is completely unusable by anyone with a sense of self-respect and a awareness that programming languages can be be…

That’s like, your opinion, and we all know the common analogy to that :D

Java is a tiny language with not too many concepts going around sitting on top one of the best runtimes with one of the biggest ecosystems. It is a very sane and good choice for almost every program out there, especially that empirically we have absolutely zero evidence for any significant difference between language productivities, other than managed languages being a boost (so your mention of C, which is arguably a language with so many faults one could fill a whole book about, is frankly, quite laughable).

Re: We want to make Nix better

#174
post #96
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…

> 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”.

I think every project would love having the money to hire someone full time to work on the documentation and evangelism.

Re: We want to make Nix better

#175

Earlier quoted context omitted.

NixOS handles nvidia cards better than any linux distro i've ever uses including Debian, Ubuntu, and Archlinux. I've only had to add a few lines to my configuration over 10 PCs and laptops.

Ok, that is good to know. But how well does it run on NVidia's Jetson line of systems? https://developer.nvidia.com/embedded-computing

The Jetson environment provided by Nvidia runs Ubuntu and are setup for you to use docker.

I have trouble understanding your question. Why do you want to use Nix if you use a system which comes pre-configured to do something else?

Re: We want to make Nix better

#176
post #93

Earlier quoted context omitted.

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

I think the only hard part is not Nix, but Nixpkgs’s not well-documented/not-stable APIs. It would be a problem in any language.

Re: We want to make Nix better

#177

Earlier quoted context omitted.

There are for anything you run as x86_64 (using Rosetta). It's also important if you're cross-compiling anything.

Sure. But I think 90% of the Nix on Apple Silicon users does not compare about cross-compiling or running x86_64 binaries with Nix. So, everyone is worse off for supporting minor use cases.

Yes but they found a solution which works for 100% of users.

I don’t really understand the complain in this thread. Using an APFS volume just works and is entirely transparent to the user.

People could just learn instead of complaining they don’t understand.

Re: We want to make Nix better

#178

Earlier quoted context omitted.

Right but the comment said they compromised on using a different directory in the end, so it could be under /opt like Homebrew, and not a root directory.

> it could be under /opt like Homebrew You can install Homebrew other places, too, for that matter. I'd only tried NixOS (bounced off, couldn't get X-Window working even following tutorials to the letter) not Nix on macOS. "Must be installed in a specific, root directory" is a hard no for me, when it comes to add-on package managers. That's one hell of an odor.

Homebrew sometimes pretends you can install it somewhere else. Like most things with homebrew, if you try, you will quickly realise this is not regularly tested.

> That's one hell of an odor.

That’s very much fine. They do that to be able to share the cache between system. There is nothing magical about the root folder by the way. It’s just Apple being annoying.

Re: We want to make Nix better

#179
post #142
post #84

Earlier quoted context omitted.

My main gripe is documentation. Look at this: https://nixos.wiki/wiki/PostgreSQL Now, the real "workflow" with nix is look at other setups, or just look at the code: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/s... And look at the code is the only reliable way to see what exactly is supported. My second gripe is the fact is hard to see what nix do. Today I hit this trouble: https://www.reddit.com/r/Nix…

Yeah, dealing with user directory is a pain, and it is a pain because you can't make it completely functional (what about passwords). And it is the only place I found where nix doesn't work as you would expect it to in my 3 years of nixos use.

Are you using home-manager for that?

Re: We want to make Nix better

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

Nix (the language) is just JSON with variables and arrow functions.

It's the easiest programming language in the world.

(Which is a problem when people start building huge projects like nixpkgs with it. It's not a language fit for programming-in-the-large, just like Javascript isn't.)

Post reply on HN