Nix: Taming Unix with Functional Programming
1–10 of 205 posts
Re: Nix: Taming Unix with Functional Programming
#2A 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 development a little more manageable, and things like Docker make (mutable) Linux development a little more manageable. Basically these both make it less painful to start over with a fresh "thing" when the system starts to get crufty.
In my view, there's a spectrum from "immutable and annoyingly rigid" to "mutable by default and annoyingly unpredictable". And the sweet spot is not at either end, but something like "immutable by default, but mutation is possible".
Re: Nix: Taming Unix with Functional Programming
#3Good video about NixOS
Re: Nix: Taming Unix with Functional Programming
#4A 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 don't see on non-Guix setups either. Plus getting things that required binaries I can't (or easily) compile myself to work is a pain.
I just can't justify fiddling with my package manager so much.
Re: Nix: Taming Unix with Functional Programming
#5A 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 use Nix on an array of devices (any combo of x86/aarch64 and Linux/Darwin machines you can imagine), and while I really do love the experience, you're right that ARM is a sticking point. It's been getting better over the past few months, but still not close to x86 packaging parity.
On the other side of that coin, I tried switching back to Arch a few weeks ago after ~4 months of NixOS. Maybe it's the sunken-cost fallacy, but Arch didn't make me feel all starry-eyed anymore. Nix feels like a really dependable piece of my workflow now, and it's difficult to imagine myself going back to Homebrew/pacman.
> the sweet spot is not at either end, but something like "immutable by default, but mutation is possible".
Flatpak tried that, you're welcome to draw your own conclusions on how that turned out. The problem is that your modifications now require build hooks for every update, and you're no longer guaranteed a comprehensive runtime. With Nix, these hooks get re-written into derivations, which (in my experience) provides a more stable, sane alternative to Docker images and Flatpaks. It's also not packaged hermetically, which means that not all Flatpaks will behave the same on all machines. Something as subtle as different environment variables or display server implementations can cause your application not to launch.
Re: Nix: Taming Unix with Functional Programming
#6A 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…
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.
Re: Nix: Taming Unix with Functional Programming
#7Neat 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 extent articles like this get to the goal of make Nix more accessible, though. It seems like preaching to the choir to me: if you like the idea of making analogies between "software is files, is like dealing with raw pointers", you'll prob'ly love diving into Nix as is anyway.
Re: Nix: Taming Unix with Functional Programming
#8A 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 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 can treat the states as immutable if we don't have a cell, which can help analysis.
Re: Nix: Taming Unix with Functional Programming
#9Great introduction and overview on the theoretic foundations of the nix ecosystem!
For people new to it, I am trying to provide a quick glossary of terms here, as I understand them after about 2 years of using nix.
* nix: a language to create derivations and the interpreter/package-manager which provides the implementation of said language. It currently offers two command-line interfaces, the stable on with hyphenated commands like "nix-build", "nix-shell", etc. And the newer, "experimental" one which includes support for nix flakes and so on, without hyphens: nix build, nix shell, nix run, etc.
repo: https://github.com/nixos/nix
docs: https://nixos.org/manual/nix/stable/
repo: https://github.com/NixOS/nixpkgs docs: https://nixos.org/manual/nixpkgs/stable/ docs nixos: https://nixos.org/manual/nixos/stable/
This tooling includes higher-level helpers for language-/environment-specific packaging, like "buildGoModule", "buildRustPackage" and so on, as well as e.g. tooling to run integration tests in a whole cluster of inter-connected linux VMs!
Packages which are submitted to nixpkgs must fulfill certain criteria, such as not using "IFD" (input-from-derivation, to simplify: "letting nix evaluate nix-code which was generated by another deriviation/"nix package".
nixpkgs is alive and well with lots of daily contribution and an everlasting effort to keep Hydra, the nix-specific CI/CD system and public binary caches up to date and responsive. Thanks to all maintainers & contributors!
* flakes are an approach to standardize a way to package nix code outside of nixpkgs but to still keep it re-usable. They are still "experimental" as the details are figured out, but nevertheless used in production. There are some frame-works to keep boilerplate low, like "flake-utils", "flake-parts" and others, as well as e.g. deployment tools like "colmena" and "deploy-rs" and re-usable helpers for system-configuration like e.g. https://github.com/nix-community/impermanence
There's lots of other stuff in the community, things like home-manager, direnv + flakes and devshells changed my workflow fundamentally to the better since I've switched. If you got the time and are still interested, join us on matrix or elsewhere :) https://github.com/nix-community/awesome-nix
Re: Nix: Taming Unix with Functional Programming
#10The article talks about the file system abstraction and that NixOS is parting ways with it:
> It is not even a new idea for Nix to propose parting ways with one of the most pervasive skeuomorphisms in computing, the file system, which naturally followed from an era where everything was a piece of paper.
What I am wondering is if this is not extremely similar to the way that plan9 handles files? As far as I understand, in plan9, there is still a file system - but there is no common root, every process can have an own view what is, for example, in /bin.