Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix: Taming Unix with Functional Programming

tweag.io

Post reply on HN
Print view View original

21–30 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#21

Post by grumbel »

nixpulvis wrote: post #13

Nix needs a new porcelain interface for it's CLIs. Moreover, this post sums up one of my biggest issues stopping me from trying Nix for real again: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... Finally, needing to rewrite everything in Nix is nice for poorly written configurations or undocumented packages in general, but seems redundant for well maintained software. Has anyone else come up with a sa…

> Nix needs a new porcelain interface for it's CLIs.

It already has one with the 'nix' command, it just needs to be manually enabled under 'experimental-features', but once done there is basically no reason to ever touch any of the old commands.

Re: Nix: Taming Unix with Functional Programming

#22

Post by soraminazuki »

rgoulter wrote: post #12
easygenes wrote: post #6

Earlier quoted context omitted.

For x86, the package availability is almost unparalleled. NixOS also has tools and options which are not all pure and declarative, they're just not considered, "the way." I find NixOS to have a bit of a high learning curve, but worth it for the power and reproducibility.

> For x86, the package availability is almost unparalleled. https://repology.org/repositories/statistics/total In terms of total number of packages, nixpkgs unstable is at 72k, while AUR is at 68k. I'd bet there are many caveats, though.

A direct comparison with AUR is meaningless though. AUR is very unusual because it allows anyone to freely upload packages without going through review. So there are many duplicates and packaging quality varies wildly.

Re: Nix: Taming Unix with Functional Programming

#23

Post by rowanG077 »

goosedragons wrote: post #4
hoosieree wrote: post #2

A few years ago I heard about Nix and NixOS. I loved the idea, but I did not enjoy the experience. Maybe the problem was I was trying to make it work on a less well-supported platform (I think it was ARM32). But the packages I wanted to install either weren't available, or I kept getting incompatibility errors. I still love the idea, but these days I feel like environment managers like Anaconda make (mutable) Python…

I recently tried Guix which is somewhat similar to Nix in theory. While I loved the idea I did not love dealing with cryptic problems resulting from it. For example I ran into an issue where one R package would only work properly if I installed other packages in a specific order, doing an update though could mess up that order breaking the package. Later updates to R broke support for certain things entirely that I d…

I mean if you don't want to fiddle with it I really don't get why you would choose Guix to test drive this way of managing your packages. It's the way less mature and less supported Nix.

Re: Nix: Taming Unix with Functional Programming

#24

Post by jnxx »

jnxx wrote: post #19

> Which other results from programming language theory and mathematics will we be able to leverage to make software build quickly, work reliably, and further tame Unix? I think Apenwarr's redo ( https://redo.readthedocs.io/en/latest/ ), based on an idea from D.J. Bernstein, is a very interesting development, because it also has the "purely functional" principle at its core - and this allows for much faster parallel b…

To add, there is another angle on immutability / purely functional definitions, which is compatibility of APIs. Rich Hickey (the creator of Clojure) has made a talk titled "Spec-ulations", in which he pointed out that there are certain operations on an API, like adding functions, adding symbols (like enumeration values), loosening preconditions (like, for example, adding keyword arguments to a function), tightening post-conditions (like, for example, removing possible error exit codes), and so on, that keep an API compatible, while others, such as removing functions, tightening preconditions, widening post-conditions (such as adding error codes or exception types), break compatibility.

And then he points out that the API itself can be seen like a persistent data structure, like a dictionary where you can add new things but not remove old things, because that would break client code. And I think this is a very important idea.

Re: Nix: Taming Unix with Functional Programming

#25

Post by rowanG077 »

nixpulvis wrote: post #13

Nix needs a new porcelain interface for it's CLIs. Moreover, this post sums up one of my biggest issues stopping me from trying Nix for real again: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... Finally, needing to rewrite everything in Nix is nice for poorly written configurations or undocumented packages in general, but seems redundant for well maintained software. Has anyone else come up with a sa…

For well maintained software it's generally a few lines of a nix definition. It precisely gets hard when it's not properly maintained. Patches, insane build configuration (I'm looking at you Intel...), binary dependencies etc.

Re: Nix: Taming Unix with Functional Programming

#26

Post by kaba0 »

nixpulvis wrote: post #13

Nix needs a new porcelain interface for it's CLIs. Moreover, this post sums up one of my biggest issues stopping me from trying Nix for real again: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... Finally, needing to rewrite everything in Nix is nice for poorly written configurations or undocumented packages in general, but seems redundant for well maintained software. Has anyone else come up with a sa…

> Has anyone else come up with a sane Nix strategy to avoid the overhead?

Didn’t need to use it for a long time now, because nowadays almost everything is packaged, but there is steam-run CLI app that will run the specified executable in a “standard-like” environment. It still doesn’t support everything, but could come in handy.

In the very early days I also just had a debian file system laying around and I machinectl-d into it (very lightweight virtual machines)

Re: Nix: Taming Unix with Functional Programming

#27

Post by goosedragons »

rowanG077 wrote: post #23
goosedragons wrote: post #4

Earlier quoted context omitted.

I recently tried Guix which is somewhat similar to Nix in theory. While I loved the idea I did not love dealing with cryptic problems resulting from it. For example I ran into an issue where one R package would only work properly if I installed other packages in a specific order, doing an update though could mess up that order breaking the package. Later updates to R broke support for certain things entirely that I d…

I mean if you don't want to fiddle with it I really don't get why you would choose Guix to test drive this way of managing your packages. It's the way less mature and less supported Nix.

I did try Nix briefly. It was even more confusing to configure for use with R IMO.

Re: Nix: Taming Unix with Functional Programming

#28

Post by hailwren »

rgoulter wrote: post #12
easygenes wrote: post #6

Earlier quoted context omitted.

For x86, the package availability is almost unparalleled. NixOS also has tools and options which are not all pure and declarative, they're just not considered, "the way." I find NixOS to have a bit of a high learning curve, but worth it for the power and reproducibility.

> For x86, the package availability is almost unparalleled. https://repology.org/repositories/statistics/total In terms of total number of packages, nixpkgs unstable is at 72k, while AUR is at 68k. I'd bet there are many caveats, though.

An unfortunate huge one is any way to interact w/ Intel Optimus. I can't be the only dev that wants to eat my gpu cake and have my battery life optimization cake too.

Bumblebee and optimus-manager both solve this in the aur.

Re: Nix: Taming Unix with Functional Programming

#29

Post by jrmurray »

While nix can be very intimidating to get going, I think for just getting developer environments spun up it can be somewhat simple. I highly reccomend trying to add a `flake.nix` to your projects. It makes on boaring new devs a breeze https://medium.com/immuta-engineering/nix-and-skaffold-for-p...
Post reply on HN