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

111–120 of 204 posts

Re: We want to make Nix better

#111

Post by ghoward »

vdijkbas wrote: post #102
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…

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

Re: We want to make Nix better

#112

Post by ghoward »

HowTheStoryEnds wrote: post #109
ghoward wrote: post #76

Earlier quoted context omitted.

> I fall heavily into the use less powerful languages "liberties constrain, constraints liberate" camp. For what it's worth, so do I. That's why my build system will allow users to set those constraints. It's a great idea. > I'd be very interested in a real world example of this, though I know that class of examples is hard to come by. There are many, but I'll say one: anything that requires iteration until a fixed p…

Would you consider lisp to be (possibly) declarative?

No, it is Turing-complete.

I was going off of the article and Nix documentation that says Nix is declarative. But if it actually is not, then there shouldn't be a problem with power.

However, Nix proponents shouldn't claim it is declarative either.

Re: We want to make Nix better

#113

Post by catern »

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…

Fascinating take! I've never heard this view before, thank you for sharing it!

Re: We want to make Nix better

#114

Post by ontouchstart »

JustLurking2022 wrote: post #107
ontouchstart wrote: post #105

I have more than 20 years of Unix experience and was getting into DevOps and CI/CD in the recent years with GitHub Actions, Azure DevOps, AWS etc. I literally discovered Nix yesterday via Andrew Kelley’s Zig demo on YouTube. I had the similar feeling as I first learned Unix tool chains two decades ago. I believe live demo and CI/CD pipeline might be some of the best use cases to get people interested in Determinate S…

I've worked with large scale monorepos in FAANG - as a rule, they all suck. Eventually you always end up in this place where you have to understand, and be prepared to debug the entire universe just to build hello world.

Totally agree. For complicated system, this essential complexity won't go away no matter how you make the UX "friendly". But good tooling will help users grow to understand the challenge of the problems as well as to appreciate the power of the solution. For people who are really interested in the solution, they will eventually dive deeper: https://edolstra.github.io/pubs/phd-thesis.pdf

Re: We want to make Nix better

#115

Post by [deleted] »

JustLurking2022 wrote: post #107
ontouchstart wrote: post #105

I have more than 20 years of Unix experience and was getting into DevOps and CI/CD in the recent years with GitHub Actions, Azure DevOps, AWS etc. I literally discovered Nix yesterday via Andrew Kelley’s Zig demo on YouTube. I had the similar feeling as I first learned Unix tool chains two decades ago. I believe live demo and CI/CD pipeline might be some of the best use cases to get people interested in Determinate S…

I've worked with large scale monorepos in FAANG - as a rule, they all suck. Eventually you always end up in this place where you have to understand, and be prepared to debug the entire universe just to build hello world.

[deleted]

Re: We want to make Nix better

#116

Post by ParetoOptimal »

amelius wrote: post #104
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…

Also: it should be able to deal with NVidia cards.

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.

Re: We want to make Nix better

#117

Post by mook »

dial9-1 wrote: post #97
techdragon wrote: post #35

Earlier quoted context omitted.

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

A newcomer is going to treat anything documented as experimental as that, regardless of what the community thinks; if it's no longer experimental, it needs to be presented as such at all the normal entry points. (None of this is unique to Nix; imagine you needed to start packaging for Windows for some reason.)

Re: We want to make Nix better

#118

Post by amelius »

ParetoOptimal wrote: post #116
amelius wrote: post #104

Earlier quoted context omitted.

Also: it should be able to deal with NVidia cards.

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

Re: We want to make Nix better

#119

Post by jackac »

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…

Recursion and merging semantics are also necessary. I use Nix and Jsonnet a lot, but Nix is much more expressive for complex structures, but the tooling being tightly coupled with the package manage make it impossible to adopt for common use cases.

Re: We want to make Nix better

#120

Post by skybrian »

ParetoOptimal wrote: post #74
skybrian wrote: post #62

The external dependency problem is somewhat solved in npm (at least, as far as many users are concerned) by writing a module that downloads the appropriate binary. For example, esbuild is written in Go, which is compiled to a different binary for each system. The NPM for esbuild has 21 optional dependencies, one for each binary that it makes available. A post-install script [1] chooses which dependency to install. It…

> The external dependency problem is somewhat solved in npm (at least, as far as many users are concerned) by writing a module that downloads the appropriate binary. This complicates working on node projects with nix in my experience. Is there a way to tell npm "no, just use my binary"? Best i've found is letting npm download it and then overwriting the npm binary with the nix one in a postinstall script. Why you ask…

If you know how to build the binary from scratch, could you teach the npm package's continuous build to do it? Sending a pull request fixing the npm package would fix it for everyone, not just nix users.

Also, I wonder if nix would be a suitable tool for generating npm packages that contain binaries? Maybe this is a way for people to benefit from nix without actually using it.

Post reply on HN