Comment by _huayra_

Comment by _huayra_ 4 days ago

27 replies

View on Hacker News

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 similar lazy nature of the language. DSL for most things, then open the hood and do actual Haskell for crazier use cases. I get that Nix started before Haskell became less academic and slightly more usable in the mainstream and has built up momentum, but the lack of tooling for understanding what is going wrong when incrementally building up a config is very confusing.

I'd be curious if anyone has go to or from NixOS compared to declarative distros compared to the atomic distros like ublue [0] and has any thoughts. I'm a bit split about what to move to next (though my >5 year Tumbleweed install on most of my machines is holding up no problem).

[0] https://universal-blue.org/

Zambyte 4 days ago

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 documented, with a nearly Arch-wiki quality manual built into the OS in the info pages.

Reply View 13 replies
  • jonotime 3 days ago

    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.

    Reply View 2 replies
    • Zambyte 2 days ago

      I'm using it on my server, laptop, and desktop. The community may be relatively small, but it is super active and easy to engage with. As a testament to how active the community is, Repology[0] ranks GNU Guix as the 5th largest repo by number of packages. Ahead of even some much more well known distros like Fedora and Gentoo.

      [0] https://repology.org/

      Reply View 0 replies
    • bjoli 3 days ago

      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.

      Reply View 0 replies
  • gf000 3 days ago

    4 years can be a very long time in a project, especially when the "network effect" hit around that time, where the active user count (and contributions) grown significantly.

    Also, the language is quite simple, it's just foreign and you felt more at home with Scheme, so you might not have given Nix as much of a chance. This is the classic "simple vs easy" from the Hickey talk.

    Documentation is no perfect, but has become quite a bit better over the years, and many of the problems that still linger are simply architectural ones of the nixpkgs repo, irrespective of language and wouldn't be solved in any other language/DSL in itself.

    Reply View 1 reply
    • Zambyte 2 days ago

      I was familiar with Haskell and had never used Lisp before using Nix (which was before I tried Guix). The fact that the Nix language was more foreign to me than Scheme seems like an important point against the language. Also, I used NixOS for months; it's not like I just hopped to it and hopped away from it after seeing the language. It was months of compounding frustration.

      Reply View 0 replies
  • SuperSandro2000 3 days ago

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

    Reply View 7 replies
    • rekado 3 days ago

      In all those years working on and playing with free software, I still cannot understand the incessant need for badmouthing other projects and calling things "half-assed". What a destructive habit!

      Reply View 0 replies
    • bjoli 3 days ago

      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.

      Reply View 1 reply
    • tempfile 3 days ago

      Can you say why you think nix modules are the "biggest plus" from NixOS? They don't even make the top 5 for me.

      Reply View 3 replies
      • SuperSandro2000 3 days ago

        When installing Nextcloud I basically have the following 4 options: - Do everything by hand and read through the docs on every update. Does not sound like fun. - Use someones Ansible playbook and hope that they update it on time. meh, also customizing it is not a walk in the park and requires some effort on my side. - Use the upstream Docker container which has the same customization problem as Ansible - Use the NixOS module. Updates are fast. Configuration changes are being handled by NixOS and I can easily inject a nginx location block in my declarative config. I also can easily describe extra bits like pre-compressed assets which then are served by nginx in my normal workflow without having to think about them at all on updates.

        overlays and the module system are THE killer features. Almost no one else has something comparable to offer and if those powerful features are well understood, they can save you soo much hassle.

        Reply View 2 replies
pzmarzly 4 days ago

I'm using Universal Blue now (Aurora, i.e. KDE flavour) and I'm very happy with it. With its large amount of pre-installed packages and drivers (including proprietary ones), I still didn't need to install any custom package (rpm-ostree) or otherwise modify the OS config (except for turning off SELinux in /etc/sysconfig/selinux). It's the most pragmatic distro I've used so far.

SaveDesktop[0] (saves flatpak apps and DE configs) and mise-en-place[1] (declarative shell environment manager) are making my installation backupable and quite reproducible (not to NixOS standards though).

For software that's not in flatpak, docker or mise, toolbox[2] and distrobox[3] are available for the rescue. Both work really well (toolbox seems better for CLIs, distrobox for GUIs), but all atomicity/declarativity is lost.

[0] https://github.com/vikdevelop/SaveDesktop

[1] https://mise.jdx.dev/

[2] https://github.com/containers/toolbox

[3] https://github.com/89luca89/distrobox

Reply View 1 reply
tomn 3 days ago

> 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 only the inputs), but whose implementation is very much not (it builds packages from a specification).

There may well be a work-around for that (it's been a while since i haskelled), but it's likely to end up with a result that's less clean than it would ideally be.

Personally I find the nix language to be a pretty good match for the tasks it is used for (though some basic static typing would be nice).

From the outside, i can see why it looks odd, but from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).

Reply View 10 replies
  • danieldk 3 days ago

    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.

    Reply View 3 replies
    • tomn 3 days ago

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

      If import-from-derivation is enabled (it normally is, it's a very useful feature, and the foundation of flakes), then some derivations need to be built to complete the evaluation.

      https://nix.dev/manual/nix/2.25/language/import-from-derivat...

      Even then functions like "readFile" are considered to be pure in nix, but not in haskell.

      > 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

      IIRC it still works that way; there's no real reason to change. Scheme isn't purely functional though (and the guix programming model is clearly imperative), so it doesn't have this mismatch.

      Reply View 2 replies
      • danieldk 3 days ago

        If import-from-derivation is enabled

        I have never looked at the implementation of IFD, but I assume that the evaluation and instantiation are still separated (and Nix will do multiple passes).

        Even then functions like "readFile" are considered to be pure in nix, but not in haskell.

        I am pretty sure that, unless you use --impure, all files that are read are required to be in the store. Since the store is read-only, it does not break purity.

        At any rate, I agree that there will be some hoops to jump through. But I think it would be possible to make a Haskell DSL to define derivations similar to Nix. But I don't know why one would want to.

        Reply View 1 reply
        • tomn 3 days ago

          > I am pretty sure that, unless you use --impure, all files that are read are required to be in the store. Since the store is read-only, it does not break purity.

          Right, but even then the logical type for readFile would be something like "string -> string" (because from nix's perspective it is pure), but in haskell it would have to be "string -> IO string" (because from haskell's perspective it is not).

          Maybe this is fine, i just suspect it would make things messier than expected.

          Alternatively this could be worked around using unsafePerformIO or the FFI, but that feels a bit far away from the idea of just making a DSL? Unclear...

          > But I don't know why one would want to.

          Same, I just think it's an interesting discussion.

          Reply View 0 replies
  • nothrabannosir 3 days ago

    I don’t understand—the language itself is completely contained and separate from the derivation. Evaluation could be done in any language and the derivation will remain the output. You can absolutely have a better language generate derivations, surely? Hell, you could use Python typescript or go if you wanted to. They’d even be completely compatible with the unholy mess of cursed bash that is stdenv.

    What you can’t port over to another language as neatly are the modules. Good riddance, id say. Undebuggable spaghetti from hell.

    > from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).

    Unfortunately I have wasted enough of my life to call myself “on the inside” and IMHO the language itself is close to the number one threat to wider adoption of nix.

    Reply View 5 replies
    • tomn 3 days ago

      > You can absolutely have a better language generate derivations, surely?

      Yes, hence guix. The issue is that it doesn't fit well into a pure functional language like haskell if you want to allow import-from-derivation or basic functions like "readFile", without putting everything in IO (complicating the DSL).

      https://nix.dev/manual/nix/2.25/language/import-from-derivat...

      What you can’t port over to another language as neatly are the modules. Good riddance, id say. Undebuggable spaghetti from hell.

      Not that it matters, but why not? Modules are written in the pure-functional bit of nix, so could be expressed in practically any language.

      >> from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).

      > Unfortunately I have wasted enough of my life to call myself “on the inside” and IMHO the language itself is close to the number one threat to wider adoption of nix.

      I guess different people have different experiences. This was mainly based on my personal experience, but if you look through the help section on discourse, the questions are not about the language (at the time of writing i didn’t find even one in the first few pages):

      https://discourse.nixos.org/c/learn/9

      There also just doesn't seen to be a big push in the nix community to replace the language. Nickel exists, but i don't see the push for that from the nix side.

      Reply View 4 replies
      • kstenerud 3 days ago

        > but if you look through the help section on discourse, the questions are not about the language

        Mostly because people don't know how to ask questions about the language. That was my experience.

        Over the past decade I've made a few forays into Nix and NixOS (I still need to revert one of my servers back to Debian from NixOS). Inevitably I find the language obtuse, and the help online is always in the form of code fragments whose purpose kinda sorta looks alright maybe, but doesn't ever seem to fit into the setup I've built. So then I'm faced with completely rearranging the structure to match the helpful code, or try to massage the helpful code into my structure (which may or may not be a monstrosity, nor could I explain what every one of the magical incantations are for). Rinse and repeat with the next problem.

        So it becomes essentially impossible to ask questions about it because I don't actually know where one thing ends and another begins.

        After awhile, I start asking myself "Why was this a worthwhile venture again?"

        I've heard good things about guix though. Might give that a try next. I'm done with Nix - burned one time too many.

        Reply View 2 replies
      • nothrabannosir 3 days ago

        Discourse is massive selection bias. The people who make it that far are not an accurate representation of the potential nix users.

        Reply View 0 replies