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

161–170 of 204 posts

Re: We want to make Nix better

#161

Post by emptysongglass »

zuzuleinen wrote: post #26

"But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources." You can use bob[1] if you want a build tool which uses Nix to install dependencies in an easy manner: just list the package names for a task and then they will be installed. I'm looking forward for all the changes in Nix ecosystem and it's a good sign the fact that they also starte…

Is Bob complementary to Devbox recently featured in a Show HN here and would you be willing to explain how you might use both together if so?

Re: We want to make Nix better

#162

Post by emptysongglass »

nextaccountic wrote: post #153
mixedCase wrote: post #51

Hot take as a NixOS user that uses Nix for work: "all" we need is a much better, sound, statically typed language to build better abstractions with. The only hard requirements I can think of are algebraic data types with exhaustive pattern matching to go with, row polymorphism, purity and good inline documentation support. I don't know if a good enough hostable language exists or if it should be a new version of Nixl…

Can Dhall be that language?

How does Dhall compare to Nickel?

Re: We want to make Nix better

#163

Post by zuzuleinen »

rgoulter wrote: post #143
ParetoOptimal wrote: post #71

Earlier quoted context omitted.

> Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. The basic way to fix this with nix is: 1) download the thing with a fixed ouput derivation: a derivation who's source has the URL and checksum of the artifact 2) copy the artifact from the nix store where said build tool stores it

In nix expressions, sure; but bob uses YAML, and uses that to drive nix.

Yes, basically you can list your packages in the yaml file and have them installed.

But you can also add .nix expression files in the same bob.yaml that can be used to build your packages when a package is not found on Nixpkgs.

Re: We want to make Nix better

#164

Post by sph »

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…

Eh, I'd just use Silverblue. You get the benefits of immutability, without having to learn a new language and weird tools to manage your workstation. I ain't got time for any of that.

Re: We want to make Nix better

#165

Post by sph »

SAI_Peregrinus wrote: post #81
rrgok wrote: post #55

Earlier quoted context omitted.

Really? It is not written in the official nix-shell manual https://nixos.org/manual/nix/stable/command-ref/nix-shell.ht... I still will try when I get to my macbook. Thank you!

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.

Re: We want to make Nix better

#166

Post by WastingMyTime89 »

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…

I think you are missing the heart of the issue.

Learning to use a lazy functional programming language remains relatively easy - we use to teach the basis in Ocaml in three hours when I was a student - and Git shows people can tolerate awful CLI tool UX.

I think your point 3 is where most of people issues with Nix lie except I wouldn’t limit myself at a lack of practical enough documentation. Nix documentation pretty much just doesn’t exist period.

If you want to use Nix, you will have to go through the packages or the implementation to understand what’s happening. That’s not very welcoming especially when you consider that’s the other Linux distributions which tried to do things differently in the past and could be a source of users for Nix OS, first of them Gentoo, have absolutely stellar documentation.

Re: We want to make Nix better

#167

Post by WastingMyTime89 »

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…

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

Re: We want to make Nix better

#168

Post by WastingMyTime89 »

infogulch wrote: post #69
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'm not convinced that any of the things you mentioned as benefits of lazy evaluation are a necessary condition to getting those benefits.

It’s not. Guix has exactly the same properties while using an eager language.

Re: We want to make Nix better

#169

Post by Mic92 »

barkingcat wrote: post #99
qbasic_forever wrote: post #94

Earlier quoted context omitted.

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?

Eelco likes `nix-env` and its new equivalent, but not many other people in the community share this opinion... That's why its in the nix documentation but everyone else uses something else.

Re: We want to make Nix better

#170

Post by kaba0 »

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…

I think the “famous” ‘Simple Made Easy’ talk makes this difference you mean quite palpable: simple is an objective term meaning something is not “interconnected” (not complected) with other parts of the code, while easy is a relative term originating from something being close to us, it being familiar.

So to most programmers, imperative code is easy and FP is hard, but on an objective basis both can be simple. In a way FP may be simpler (according to the talk), as e.g. mutable variables complect/mix together values and time.

Post reply on HN