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

51–60 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#51

Post by [deleted] »

hoosieree wrote: post #18
pca006132 wrote: post #8

Earlier quoted context omitted.

I don't think the problem you encountered is due to immutability, the problem is due to the implementation, which is now improved due to better documentation and more package support. The possibility of mutation alone will break a lot of assumptions and make program analysis a lot harder. I personally prefer no mutation at all or only when wrapped inside a cell (UnsafeCell), similar to rust. For the latter kind, we c…

That's fair. I blamed immutability when I should have blamed the implementation. Thanks for helping me realize my mistake. :) Availability of packages is what makes or breaks a distribution, though. If I can't (easily) install the software I need to do my job, I choose a distribution that can. My home Ubuntu server isn't bringing me joy, so maybe now's a good time to give Nix another shot. Fingers crossed for Nvidia…

[deleted]

Re: Nix: Taming Unix with Functional Programming

#52

Post by pxc »

revscat wrote: post #48
atemerev wrote: post #17

Nix is React for system configuration.

So… over-engineered and expensive to maintain?

Overengineered? Maybe, depending on your use case. NixOS is pretty popular as a desktop OS within the community, for example, and I could see a case that its guarantees and strictures are overkill there.

But maintenance is really easy. You're basically never forced to rewrite or throw away tons of config. Doing literally years worth of updates at once is typically pretty painless. (Adding new packages to Nixpkgs or new features to NixOS can range from trivial to very hard, just depends on the details.)

Re: Nix: Taming Unix with Functional Programming

#53

Post by rgoulter »

revscat wrote: post #45
rgoulter wrote: post #7

Neat article. For me, the key takeaways are: 1. 'Nix is to `tar -xf && make && make install` as C/C++ is to assembly'. In many ways, Nix applies the same kinds of improvements that other technologies have. 2. Nix does try and create an elegant programming model of Unix systems.. while the Nix programming language is pure, it interfaces with the Unix system by reading files and outputting files. I'm mixed on to what e…

Same. I read almost every nix-related post that I see pop up on HN. I want to be convinced. I have not yet been. It seems like `brew install` with (many) extra steps, with little meaningful gain.

I'd describe many of the benefits for developers as like "docker, without containers".

e.g. if you want to try out helix, you could run `nix run nixpkgs#helix`, and it would download + run helix without installing it. (Or you could run `nix shell nixpkgs#helix` to add helix to the PATH in the current shell, without installing helix, etc.).

One use case I'm excited about for developers is the ability to declare the dependencies needed to build the project. -- So rather than copy-pasting `apt-get install` commands, you'd rely on nix to fetch the installed dependencies. (e.g. I love that I don't have to worry about what packages to install to work on qmk_firmware, or repos which provide a nix shell).

VSCode's Remote Containers supports a similar workflow to the latter.. but, it relies on containers.

Re: Nix: Taming Unix with Functional Programming

#54

Post by revscat »

rgoulter wrote: post #53
revscat wrote: post #45

Earlier quoted context omitted.

Same. I read almost every nix-related post that I see pop up on HN. I want to be convinced. I have not yet been. It seems like `brew install` with (many) extra steps, with little meaningful gain.

I'd describe many of the benefits for developers as like "docker, without containers". e.g. if you want to try out helix, you could run `nix run nixpkgs#helix`, and it would download + run helix without installing it. (Or you could run `nix shell nixpkgs#helix` to add helix to the PATH in the current shell, without installing helix, etc.). One use case I'm excited about for developers is the ability to declare the de…

We use Brewfiles to install binary dependencies needed by various projects. This is only for developer’s machines, but it’s lightweight and fast: `brew bundle` and you’re done.

Re: Nix: Taming Unix with Functional Programming

#55

Post by pxc »

mattarm wrote: post #40
grumbel wrote: post #21

Earlier quoted context omitted.

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

> it just needs to be manually enabled under 'experimental-features' Same with flakes. My impression is that Nix is either on the cusp of a major paradigm and usability change, or the status quo will be forever in a state of having "wrong defaults."

> My impression is that Nix is either on the cusp of a major paradigm and usability change, or the status quo will be forever in a state of having "wrong defaults."

I think probably both. The Nix community is host to very diverse and partially overlapping experimentation, and features like rollbacks and version pinning make the bleeding edge feel relatively safe, further fostering such experimentation.

The new Nix CLI will be huge for new users and for adoption once it's finalized. But there will probably always be a bunch of Nix users doing weird, cool shit that everyone kinda wishes was 'here already' for mainstream use.

Re: Nix: Taming Unix with Functional Programming

#56

Post by fesc »

Man, there’s a lot of negative comments here. Just to add a different experience: my company loves Nix, it makes it really easy to integrate new tools into the dev/build environment without needing to document which packages, configuration, … a developer needs to apply to their machine manually.

There’s nothing like it, really.

Re: Nix: Taming Unix with Functional Programming

#57

Post by yakshaving_jgt »

rgoulter wrote: post #53
revscat wrote: post #45

Earlier quoted context omitted.

Same. I read almost every nix-related post that I see pop up on HN. I want to be convinced. I have not yet been. It seems like `brew install` with (many) extra steps, with little meaningful gain.

I'd describe many of the benefits for developers as like "docker, without containers". e.g. if you want to try out helix, you could run `nix run nixpkgs#helix`, and it would download + run helix without installing it. (Or you could run `nix shell nixpkgs#helix` to add helix to the PATH in the current shell, without installing helix, etc.). One use case I'm excited about for developers is the ability to declare the de…

Important difference: Docker is repeatable, but not reproducible. Nix is reproducible.

Re: Nix: Taming Unix with Functional Programming

#58

Post by pxc »

xyzzy_plugh wrote: post #50
agentultra wrote: post #34

Nix seems great for build servers. This is a great introduction to the motivations behind it. I'm not sold on using it for managing developer environments (another use case it is often used for). It "solves" the problem that developers might be using different versions of libraries or compilers on their machines... but it comes at the cost of having to learn a whole new programming language, a configuration language,…

Hydra is arguably one of the scariest parts of Nix: A giant, bespoke CI system written in C++. Arguably it shouldn't exist. Nix can and should easily slot into any CI tool.

There are couple of CI/CD systems being produced by startups that aim to fill that role, based on BuildKit/Docker. For now, Nix is still way better than they are in many ways, with the notable exception of Windows support.

Maybe visible interest in them can push forward Nix community developer interest in polishing Nix for the same use cases.

Re: Nix: Taming Unix with Functional Programming

#59

Post by bogota »

fesc wrote: post #56

Man, there’s a lot of negative comments here. Just to add a different experience: my company loves Nix, it makes it really easy to integrate new tools into the dev/build environment without needing to document which packages, configuration, … a developer needs to apply to their machine manually. There’s nothing like it, really.

I dont think anyone is being negative at least not the top level comments i read. I like nix but i gave it a test run at my company and no one could figure out how to make any change that wasn’t a copy and paste of what i had done.

The docs don’t help much unless you really go diving into them and most people who just want the software to run don’t want to spend the time learning it. I don’t blame them.

This is a very valid criticism of any software. Its why things like docker (containerization) win out even when it was technically around for years before. Someone made it easy to use so people used it.

Re: Nix: Taming Unix with Functional Programming

#60

Post by [deleted] »

yakshaving_jgt wrote: post #57
rgoulter wrote: post #53

Earlier quoted context omitted.

I'd describe many of the benefits for developers as like "docker, without containers". e.g. if you want to try out helix, you could run `nix run nixpkgs#helix`, and it would download + run helix without installing it. (Or you could run `nix shell nixpkgs#helix` to add helix to the PATH in the current shell, without installing helix, etc.). One use case I'm excited about for developers is the ability to declare the de…

Important difference: Docker is repeatable, but not reproducible. Nix is reproducible.

[deleted]
Post reply on HN