Live data from Hacker News

Nix – Death by a Thousand Cuts

dgt.is

201–210 of 336 posts

Re: Nix – Death by a Thousand Cuts

#201
post #174

I've been on the fence about Nix. I've wanted to love it (and do love the concept), but between the Waiting-for-Godot situation for flakes, the weird language, and the occasional political infighting I've seen pop up about the community, I still haven't switched. I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the simil…

> I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the similar lazy nature of the language. My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by…

My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by only the inputs), but whose implementation is very much not (it builds packages from a specification).

Evaluation is completely pure (at least with flakes, which disallows querying environment variables, etc.). Evaluation of derivations will result in .drv files in the store, but that does not add impurity to the language itself. Building the .drv is a separate step (instantiation).

You could totally write something that generates .drv files in a different language and use Nix for instantiation (building). If I am not mistaken, this is how Guix started - they evaluated derivations defined in scheme to .drv files and then let the Nix daemon build them.

Aside from that, as a Nix user, I am happy that Haskell is not the language. Nix is a very small, simple language that is easy to wrap your head around and does not lead to a lot of abstractionitis. A want to say this in a way without painting a caricature, but the Haskell community has a tendency to pile on a lot of abstractions and I would hate to see a Nix with monad transformers, lenses, or whatever is popular these days.

Re: Nix – Death by a Thousand Cuts

#202
post #90

Earlier quoted context omitted.

"Trying to hack on other people's junk with NixOS is just asking for pain." To me that's a large part of the very definition of a useful general purpose OS is that it's flexible and enables you to do whatever you need to do today, without the developers having previously somehow planned and provided for exactly that thing. It's like the systemd argument all over. The exact thing systemd aims to prevent is the exact t…

Not to be too presumptuous, but you sound like someone would might like Gentoo. It still works without systemd, though it does install sys-apps/systemd-utils (mostly for the /dev FS stuff). I'd say the focus of Gentoo is on "managing choice", and it is true that some choices can make your system(s) diverge from the most frequent instances floating around (but those tend to be systemd-based these days). It's still pre…

Safe presumtion. I never used it for real but for instance I like freebsd and the ports system, prefer macports to brew etc.

Re: Nix – Death by a Thousand Cuts

#204
post #72
post #69

Earlier quoted context omitted.

The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better. The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.

It's basically, I refuse to learn how to containerize. Just learn, use, promote best practices and stop forking the ecosystem _even_ further... There, I got that off my chest.

Containerizing an application is far easier than packaging an application for Nix - I think most avid Nix users would agree with that.

The reason why Nix users "refuse" to containerize is that Nix packages and their associated ecosystem come with a host of benefits that their containerized counterparts do not.

Re: Nix – Death by a Thousand Cuts

#205
post #128
post #95

Earlier quoted context omitted.

Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside…

> I think we've gotten used to development environments being a shitty experience to the point where it seems part and parcel of programming… I have staunchly refused to allow this at my current employ, and I’ve been there long enough where I can steer this. This isn’t acceptable and all it does is help introduce inconsistency and regressions. I realize I am fortunate in that I can effect change at my job in this are…

What's been your strategy for doing this

Re: Nix – Death by a Thousand Cuts

#206

Earlier quoted context omitted.

Huh? I use Nix to create containers. Nix is a programming language, a build tool, a package manager and an entire ecosystem of extremely powerful tools. The entire reason why I use Nix in the first place is because it allows me to containerize with _better_ reproducibility than docker itself. I do get where you're coming from though. It's not immediately clear that Nix can do all this stuff. Nix is a lot more than ju…

> Nix is a programming language, a build tool, a package manager and an entire ecosystem of extremely powerful tools You have identified part of the problem.

I agree. This _is_ a huge problem.

Re: Nix – Death by a Thousand Cuts

#207

The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".

I think that's a bit reductive, but I get the intent. A lot of people see systemic problems in their development and turn to tools to reduce the cognitive load, busywork, or just otherwise automate a solution. For example "we always argue over formatting" -> use an automated formatter. That makes total sense as long as managing/interacting with the tool is less work, not just different work. With Nix I still think it…

I just started using Flox last weekend and so far it has been quite nice experience. There are two things I don't like, though:

1) The Homebrew package is a cask that installs also Nix. While I like Flox, I don't want my systems to be married to it. Yes, I know about install option with "generic Nix", but I'm using Homebrew with Brewfile both in macOS and Linux, and I would like the Homebrew package to be just Flox.

2) Documentation is OK for getting started, but not for anything more than that. There are nice manifest.toml examples for many use cases in floxenvs[1] but you need to find those first. Also I'm not sure how I feel about inline shell scripts in toml. While it works, separate files would be easier to handle, at least for me.

[1]: https://github.com/flox/floxenvs

Re: Nix – Death by a Thousand Cuts

#208
post #63

Earlier quoted context omitted.

I switched away from Nix OS and eventually landed on GNU Guix, which I have stayed on for about 4 years now. One of the main reasons I switched away from Nix was because of the language, and how underdocumented it all felt. GNU Guix was a breath of fresh air, using a language with decades of academic backing outside of the context of Guix (SICP was awesome for getting into it) and the whole system is very well docume…

Guix has stripped away the biggest plus from NixOS: the module system and replaced it with a half assed system

I mean, modules are just regular guile modules. It feels somewhat clunky, but at the same time you can use guile's introspection to do fun stuff.

I always found it more flexible, but on the other hand I never liked NixOS modules.

Re: Nix – Death by a Thousand Cuts

#209
post #63

Earlier quoted context omitted.

I switched away from Nix OS and eventually landed on GNU Guix, which I have stayed on for about 4 years now. One of the main reasons I switched away from Nix was because of the language, and how underdocumented it all felt. GNU Guix was a breath of fresh air, using a language with decades of academic backing outside of the context of Guix (SICP was awesome for getting into it) and the whole system is very well docume…

Oh, I'm interested. Are you using it on servers, or desktop? My concern is the community is small, while Nix's has been booming.

I am using it on my home server that serves my web page and also a lot of things for my home network.

It runs some guix containers and some VMs. Nothing fancy.

All declared in a couple of files.

Re: Nix – Death by a Thousand Cuts

#210

I use NixOS as my daily driver. I concur. I wouldn't recommend it for most people (even for me, when I decided to give it a try). I'd probably just go Arch if I were to do it over again. The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too…

After spending some time on NixOS I basically decided to hold off until flakes become official and the docs are written with them in mind. In the mean time I just run Arch with Nix home-manager and I'm happy. I've developed enough good habits over the years that I don't get breakages, and home-manager allows me to easily sync my dotfiles across machines..

What makes you reluctant from using flakes? I initially thought I'd never have a need for flakes but after spending an hour on YouTube and Googling, I converted to flakes.
Post reply on HN