Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This past month, I have spent a decent amount of hours (7+) trying to setup nix on my mac with nix-darwin, and failed.

Most tutorial out there encourage you to download someone else's configuration to get going. I don't want to do that. I want to understand at its core how this thing works.

I've read the official nix language documentation, watched YouTube tutorials, read 3rd party tutorials, and still couldn't get going with a simple configuration that would install a few packages.

The nix language is also really unpalatable to me. But I could deal with that if the examples out there showed a consistent way of doing things – that's not the case. It seems one same thing can be done many different ways – but I want to know and do it the right way. I would generally turn myself to the official best practices documentation, except nix' is very short and doesn't help much.

I really want to use nix. There's no question about its advantages. But nix just won't let me (or maybe I'm too old to learn new things).

That being said, I'll probably give it another try this month...



> The nix language is also really unpalatable to me.

yeah, I wish I could give you some "it gets better" good news, but...

I've used NixOS as my daily driver for ~10 years, including the laptop I'm typing this on.

I love NixOS-the-OS, I love nixpkgs-the-ecosystem. but I still hate Nix-the-language.

it's like Perl and Haskell had a drunken hookup that produced a child. and then abandoned that child in the forest where it was raised by wolves and didn't have contact with another human until it was fully grown.

(to answer the inevitable replies, yes I understand functional programming in general, and yes I am aware that Guix exists)

for simple NixOS administration, you can get pretty far with treating configuration.nix as "just" a config file, rather than a program written in a Turing-complete functional language.

writing your own modules or flakes, or re-using flakes published by other people, is strictly optional. make friends with The Big Options Page [0] - anything you find there can be dropped into your configuration.nix without really needing to understand Nix-the-language.

0: https://search.nixos.org/options?channel=25.11


Which part of the nix language looks like Perl?

I actually find the language simple and easy to learn: It's just untyped lambda calculus with dicts and lists.

(I, too, would like static types though.)


I'm not them, but TIMTOWTDI is a bad thing, and Nix suffers from it. That's the main Perl-ism I can think of.


> The nix language is also really unpalatable to me.

It may not really help the case, but I firmly believe that it is not the language, but the ecosystem, and is more of a fundamental issue. But maybe putting the blame elsewhere could help accept the situation.

So anyways, the language is pretty much a lazily evaluated JSON. But even if it were something else (insert your favourite language), the problem ultimately is that packaging software is complex especially in a non-standard way, with endless edge cases, requires whole libraries and conventions and this is simply not a well-trodden path. Most programs simply hard-code "traditional" Linux file system conventions and those have to be patched in some way.

So the hard thing is not "is this really a function application here", when writing new Nix code the hard thing is simply knowing that for python there already exist this abstraction in nixpkgs, but to use it you need this folder structure and this build tool, etc. Especially when there are multiple abstractions for the same thing because it's an absolutely huge repository with countless packages.

But the benefits absolutely make up for it big time - there is simply no going back from Nix imo. I would honestly feel constantly "dirty" with any other traditional package manager, it's like file "versioning" before version control.

(PS: just grep for use cases of a function you are looking for. Also, find a "blueprint" package and start from there, e.g. another program written in python with a few native deps)


I've used Nix for at least seven years, and I firmly believe that the language is a large part of the problem. Yes, the Nix language is "just another lazily-evaluated pure FP language in the ML tradition" and "it's like a lazily-evaluated JSON", but it has several large footguns. The biggest one is that spaces are use to separate elements in list literals as well as for function application. The second is the lack of a usable type system, in the sense that the programmer cannot assert the types of values in a useful way. Instead, you have to rely on comments and convention to know what a function's arguments are.

These two design warts also interact with each other really badly: If you try to put a function application into a list and forget to enclose it in parentheses, you instead insert the function as one element in the list and its arguments as successive elements. The usual result is "expected an X but got a function" error in some completely unrelated part of the code.


It is the language. The module system is both semantically indispensable and a second class citizen. It's another language, implemented on top of Nix. Once you have a userland "if" reimplemented in your language you know you're in a bad place. (`mkIf`)

Maybe lazy evaluated attrsets can help make a dent, but still the lack of static types for module code is beyond painful. It's hostile.

I believe Nix is worth it in spite of this, and I'll advise anyone to learn it, it truly is the way forward, but by god do I hope it's not the last step on this journey. Please, Lord, please don't let nixlang be the final iteration XD


I read the same complaint about the language from people I follow who love and actively promote Nix. So it's not just you.

Sorry for adding to your frustration of "just follow what someone else did" but I recently went all-in on managing my Mac (programs, dotfiles, configs, etc) via Nix* when setting up a new machine recently. https://github.com/landaire/config/tree/main/modules

*Nix + homebrew, mostly because Homebrew packages more macOS applications.


I've been on a similar journey this past month, although it sounds like mine went a little more successfully. I've managed to get a repo setup which contains a nix flake with nix-darwin configuration, and it also calls into some home-manager modules which I also use on a linux device as well. I do agree, the nix language isn't particularly to my taste either.

I know you're hoping to go from first principals but I'm happy to share the repo if you want (email in my profile).

Aside from that, what issues did you run into? I'm keen to know if I've just not gone deep enough and will soon hit something.


I had the same reaction my first year. I found the NixOS documentation to be very poor and the lack of a single set of best practices (e.g., imperative, declarative, home config, flakes) to be frustrating.

I switched a couple devices to Guix and was at first encouraged by their much better docs, but the lack of features and battle testing has been a problem with longer use.

I've mostly been happy to go back to NixOS thanks to LLMs. Even a year ago, AI was very good at updating Nix configs and fixing any errors. Ideally Nix would have better docs and a more intuitive unified config system, but LLMs have made it usable and the best solution for now.


I struggled with this too and it took me a while to accept that there is no right way. There are many ways, and there is a lot of legacy style out there, but ultimately you have to do what works for your own productivity/sanity.


you should look into learning how to write modules. nix-darwin at its core is a somewhat underbaked port of nixos to mac OS with the same very useful module system. otherwise look into just getting home-manager working and working your way up.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: