9 ms·

NixOS has one fatal flaw

JamesSwift 3y ago
The main thing that made understanding the language much easier was the realization that you arent actually looking at imperative commands. Nix is just a big lazily-evaluated JSON blob. All of the language is just commands to manipulate the values of that JSON. Once you understand that, I think its more straightforward (except some funky syntax like `//`)
- hiAndrewQuinn 3y ago
  This is how I think of Dhall as well, which I highly recommend. https://dhall-lang.org/ https://dhall-lang.org/
- __MatrixMan__ 3y ago
  Agreed. For me it helped to think about how modules are composed--something about the order-invariance aspect of it made me understand why this was a good language choice. Suppose you were actually using JSON. You've got X = {a:1, b:2} and Y = {b:3, c:4} In imperative land, if you start with X and then apply Y, "b" will be 3. And if you start with Y and then apply X "b" will be 2. That's bad if you're a package manager, you don't want the order that packages are installed to change their function. The imperative solution is to add some kind of metadata which indicates whether X and Y are compatible, and to consult some kind of solver which prevents you from even trying to do the thing that would create the order-dependence nightmare. But because of how the Nix language works, you never even get to the point where you're clobbering things. Nor do you have to consult a version solver. The fact that you've tried to make "b" both 2 and 3 is a language error. It's as close as you can get to making config errors syntactically invalid and helps you sidestep a whole domain of trouble. It also means that pretty much all problems are code problems, and that's a dimension that we know how to collaborate in. sorta.
anon291 3y ago
Unfortunately if you don't have a pure language, the benefits of nix disappear and you're back in sad imperative land. I'm a nix language fan. The main mistake is lack of typing and debuggability (esp for recursion). The syntax is intuitive
- aidenn0 3y ago
  I don't think it has to be pure necessarily, but you need some form of lazyness for things to work the way they work now. You could implement it in a non-lazy language by using explicit thunks, but I don't know if that would be better. > The syntax is intuitive Let me guess: you come from a ML or Haskell background?
  - anon291 3y ago
    > Let me guess: you come from a ML or Haskell background As a professional computer scientist I am familiar with all the major programming paradigms and all the general syntactic modes, whether that be C-like, Python-like, Ml-like, prolog-like, lisp-like, etc. Yes I have worked professionally as a ML and Haskell programmer but I currently work on Assembler and c++, so my background is equally in both pots. Nix is entirely unsurprising to anyone who is familiar with lambda calculus which should be all computer programmers really. It's fundamental. It'd be like a linguist not knowing what a preposition is.
    - aidenn0 3y ago
      > As a professional computer scientist I am familiar with all the major programming paradigms and all the general syntactic modes, whether that be C-like, Python-like, Ml-like, prolog-like, lisp-like, etc. This is an overly pretentious opening for a comment even for HN. It certainly makes me feel the need to point out that the majority of people on HN (including myself) are most certainly not "professional computer scientists." Neither are users of Docker nor system administrators. Opening your comment this way is implicitly excluding those people from using Nix. > Nix is entirely unsurprising to anyone who is familiar with lambda calculus which should be all computer programmers really. It's fundamental. It'd be like a linguist not knowing what a preposition is. I took my computer science classes from a department that was probably slightly more math-focused than the median CS program. Among those classes was a (optional to non-honors students) 400 level theory of computation class. I don't believe there were more than 2 hours of lecture regarding the lambda calculus, just as an aside that it was an alternate model to Turing Machines and was fully equivalent. We had a single weekly assignment that involved it. I encountered the lambda calculus more in my philosophy classes than in my Computer Science classes. On top of all of that, I know I am not alone in finding many forms of mathematical notation, including the lambda calculus, to be poor notation for writing software.
__MatrixMan__ 3y ago
Something will evolve from that space which doesn't have the flaw. Whether that thing will be called Nix or not, I don't know. I think that means that it's not a fatal flaw, it's just a regular flaw.
- jamies 3y ago
  I totally agree. I love and hate Nix every day that I use it. I hope that someday they'll make it more user friendly, but I suspect it'll be someone else with a new approach.
  - tempay 3y ago
    I struggle to see how another tool will take the spot. I think the power of Nix is that the underpinnings are so pure, academic and well thought out that you can rethink package management in a much cleaner and sane way. Unfortunately that results in the UI not being the priority, though I think the opposite approach results in a conventional package manager with their many flaws and trade offs. I generally think the UI first approach is a better way of building tools, but there are special cases where it doesn’t work due to their being so many edge cases that you need pure underpinnings to make it actually work (e.g. version control).
    - abathur 3y ago
      I feel this. I ~empathize with people who wish it were simpler, and agree there are too many sharp corners. (For example, the traditional CLI certainly left a lot of room for improvement.) I can vaguely imagine the prospect that something new gets this more-right than Nix, but on some level I also suspect most ~complainers aren't appreciating the scale of the domain complexity Nix closes over in order to forge The Nix Way and square decades of contrary software development/packaging/deployment practices with it.
- aidenn0 3y ago
  I'm not convinced that the upsides of Nix don't necessarily include the downside. Docker files are basically "copy these files in and run these commands with full network access" which is a recipe for both "easy" and "not reproducible" Oh, I need python? "RUN apt-get install -y python" done. Which python version is installed? I don't have to think about that. If you want to ensure the inputs are the same, then you need to impose structure. That structure is a large part of what is confusing with Nix. I hate the Nix language as much as the next-guy, but I don't think that if it were Javascript instead, everyone would be like "oh this is so easy!"
baby 3y ago
My personal take is that functional languages are fine if users don’t have to touch them, but will prevent a product from reaching critical adoption if users are facing them directly.
corethree 3y ago
There needs to be two levels of configuration. One is just straight up a config file and the other is the nix language. Average users should not need to ever touch the nix language. They should only touch a config file. This config file needs to be so simple that it Can be configured with a GUI. Isomorphic configs when run with a formatter should come out identical. What I mean by this is if you have a machine with say version 3.123 of an app installed there is only one possible config file that can describe this configuration. There shouldn't be 50 possible ways to program that same configuration.
- Niksko 3y ago
  It's not quite the same, but Home Manager feels a little like what you're describing.
  - corethree 3y ago
    Never used it, it's been a bit since I used nixos. Still I'm sure there's a lot of warts.
  - aidenn0 3y ago
    Home Manager is literally the opposite of what they are describing.
- Cyph0n 3y ago
  This is exactly the goal behind NixOS the Linux distro (the worst part about Nix is the naming!). The distro itself and module authors give you high-level building blocks that allow you to configure the system declaratively (e.g., create users) as well as install & configure software. Of course, you still need to write Nix to use these options and modules. But if you take a NixOS configuration and apply it on a different machine, it should do exactly the same thing (modulo hardware-specific config options). I am a relatively recent NixOS convert and I quickly decided that I will be using it exclusively on my personal servers going forward. I even wrote a tool that simplifies migrating Docker Compose stacks to NixOS: https://github.com/aksiksi/compose2nix https://github.com/aksiksi/compose2nix
_8j50 3y ago
Personally it's harder to reason about systems where you define the desired state and it magically happens, this includes functional languages. I have no idea why people think that is better. I always want to command the system and be able to understand the processes it will undergo to implement that change. Even if it is reliable, it's difficult to understand or be confident in a system whose inner workings feel like a black-box.
- eternityforest 3y ago
  I've always been pretty comfortable with black boxes, as long as they're repeatable and have fewer bugs than I would expect to produce by hand. I wonder if it has to do with mastering a real life skill before learning to code, if you can draw or play an instrument well maybe it sets you up for more of a direct action mindset?
  - _8j50 3y ago
    I think it has more to do with desiring control. Black boxes feel like out of control. I can reason about how transport vehicles work for example but if there was a quantum teleport machine that only wants my destination and I get magically zapped there, it would be amazing but plenty of people including me would have a hard time trusting it fully because we can't have an intuitive understanding of how it works (cars,trains = wheels go round and round lol).
- dqv 3y ago
  I mean anything new that I'm experiencing for the first time is magic because I don't understand how it works. Perl was magic until I learned what the weird syntax meant. I've learned a little about Java over the years and so it seems less magical, but there still seems to be a lot of magic I can't comprehend. I think the issue is that Nix is "too much new", not too much magic. Because I have familiarity with Nix, I can go to e.g. the PostgreSQL build file [0] and mostly make sense of what's going on, just like any other language I'm familiar with. Now if you give me something like a debian package, I have no idea WTF is going on. If anything goes wrong with a package installation, there isn't much I can do, except try to build outside the package manager. With Nix, I have a few options, from simply overriding the upstream repository to forking the broken module to fix whatever problems I'm having. It's also really nice to be able to be confident that what is in the Nix file is what's in my environment. As the syntax and libraries became more familiar, so did my confidence using Nix. That's pretty much how it works with most things, I think. [0]: https://github.com/NixOS/nixpkgs/blob/203ecda835bcf69633df7183459283543dd4a874/pkgs/servers/sql/postgresql/default.nix https://github.com/NixOS/nixpkgs/blob/203ecda835bcf69633df71...
Niksko 3y ago
My biggest frustration with Nix is the lack of typing. Writing anything more than the basics, I feel like I quickly run into an issue of not being able to reason easily about what structures I'm manipulating, and I haven't gotten very far by trying to lean on the editor I'm using either.
- abathur 3y ago
  There's some prospect of Nickel (https://github.com/tweag/nickel https://github.com/tweag/nickel) meeting this need, though haven't tried it and can't really vouch. Typing might be really helpful for building your own layers up, but I don't know if it can meaningfully help with problems around consuming existing Nix ~APIs.
  - evanjrowley 3y ago
    Another new contender in the typed Nix space if Garn, which allows one to interact with Nix via TypeScript: https://news.ycombinator.com/item?id=38112416 https://news.ycombinator.com/item?id=38112416
- wharvle 3y ago
  Same. At this point I've resolved I'm never again writing in a language without static typing, unless someone's paying me to. Too much of a headache.
gipp 3y ago
It's not exactly a 1:1 comparison, but NixOS' tight and extremely simple integration with systemd and podman has made NixOS native containers a pleasure to work with. OP seems to maybe not be aware of them?
noelwelsh 3y ago
Comments here arguing about functional languages etc. really miss the point from my experience. The usability issues for me were: - The Nix homepage didn't explain the actual benefit of using Nix. - Different introductions recommending vastly different ways of getting started. E.g. flakes vs non-flakes. Even now, the homepage is bad: > Nix is a tool that takes a unique approach to package management and system configuration. Learn how to make reproducible, declarative and reliable systems. First sentence tells me nothing. Second sentence doesn't differentiate it from Docker. This is, I believe, the fatal flaw of Nix: the developers just don't get how to present something that is accessible to users who are not deeply invested in the system. I don't care what language Nix is written in. I understand it's bad for various reasons (and I'm a fan of programming languages and I would probably agree with the reasons) but as a user I just want the equivalent of installing software, configuring it, and rolling back if things are messed up. If I can't do that in a few expressions or commands or whatever, I'm not interested. I don't care about flakes vs whatever. In fact I don't care about flakes at all. I want to type `nix do-the-thing-I-am-actually-interested-in` and have it Just Work.
- puzzledobserver 3y ago
  I tend to agree. I am comfortable with writing functional programs, but I have tried and failed multiple times to grok the Nix documentation. The complexity is not because "functional programming is hard", but because the documentation is terrible. To get me started with Nix, the documentation needs just a few things: 1. Internal consistency: A large fraction of the documentation is spent talking about how great flakes are, with a (last time I checked) big disclaimer at the top saying that flakes are experimental. Another fraction of the documentation talks about how great declarative installations are, while the third happily uses nix-env which, on the surface, seems no different from [apt / dnf] install. 2. How to use the package manager, for dummies. The last time I tried to install NixOS, I tried to install Z3 and its Java bindings, but got completely lost with the "also install the Java bindings" part. I'd rather just spin up a Docker container with my favorite distribution, and put my trusty magic installations there. 3. How to use Nix the language, for dummies. For people wanting to understand the system better than the dummies from part 2. I remember some magic ellipsis, and remaining confused about what they're about. 4. Really what Nix the language is about, for non-dummies. The documentation currently conflates the last three points, and is internally inconsistent. It is also not clear where users can turn to for help. And then, I install Silverblue on my machine, and for the most part it is rock solid and easy-to-use. Sure, there are some installation commands that I need to run at the beginning of time, but I can put those in a script, and there's my nearly declarative install.
sconi 3y ago
I get very similar vibes to early Docker as I do about Nix today: it requires doing things very differently, is difficult ramp up on because of that, but those who pay the cost to invest the time are gaining an advantage now by their ability to do dazzling things by adopting early.
- Avshalom 3y ago
  What dazzling things is docker facilitating? kinda just thought it was marginally decreasing sys-admin/op-management costs.
  - sconi 3y ago
    Back in Docker's day it was (basically) the only thing out there that let you reliably package up an application in a portable way from any Linux distribution to any Linux distribution - before Docker it was prohibitively difficult to build your application on your Ubuntu desktop and run it on your CentOS servers because you had to wrangle system packaging, library differences, and see the app run in the same way as it would in production. Docker turned the runtime into one consistent thing everywhere (and the ability to ship it to the deployment target). That's less novel in 2023 but solved serious problems a decade ago. In 2023 reproducible builds are important as reflected by efforts like Debian's reproducible builds or SALSA and nix zooms way beyond that to solve downstream problems, too
    - Avshalom 3y ago
      Speaking as a linux user since 2004: it absolutely was not "prohibitively difficult" as shown by every application pre-docker. Beyond that, it's hardly dazzling
  - wharvle 3y ago
    It lets me run up-to-date daemons on my home server, with excellent uptime, on some old-ass version of Debian I never bother to update (don't worry, it's not routable from the public Internet) and without having to touch systemd (or sysv init, or openrc, or whatever), having written nothing but a single short shell script for each service. I could take all my exact same knowledge and scripts (and a backup of the data directories, helpfully and completely documented in those same shell scripts) and spin my whole stack up again on basically any other distro, only having to google what installing Docker looks like for that system. Different init system? Older/newer packages than I want in the distro's official repos? Some futzing-about with third party repos needed to add to get what I want at a version that's not three years old? No option but downloading a tarball and dicking around with that, on this distro? Package on this distro stores some daemon's config in a different places from the last one, and carves it up differently, so you can't just drop in your old config and have it work? This distro or version puts data for this daemon somewhere different, so now your backup scripts are fucked? I don't have to care at all. About any of that. I no longer have to give any shits which distro or version my home server's on (within reason) and anything I learn managing it transfers basically anywhere. I can turn around and immediately apply nearly 100% of that skillset to any day-job I've had in the last decade or so.
smilliken 3y ago
Nix is hard in the way that programming is hard. Not everyone gets over the activation energy to be successful. The ones that do don't regret the effort. Nix is complex because the problems it solves are high complexity problems that other systems don't solve. Docker is not a substitute for Nix. The solution isn't to use a weaker tool, because the weaker tool doesn't solve your problem. It's not uncommon to see a programmer use a spreadsheet, but you wouldn't expect to see a programmer use a spreadsheet where a database is needed. And you don't see people trying to use garbage-collected languages to write operating systems, even though they are easier to use than C. It's perhaps inefficient when a tool is too powerful for what you need, but it's a fatal flaw if the tool you use is too weak for what you need. Nix let's you control your dependencies in a way no other tool even attempts. I can pin and patch any combination of dependencies, even conflicting ones in single environment, with reproducible builds— I'm in control of every detail. I would never consider a downgrade from that, but I'm open to upgrades if something even more capable came along.
- Cu3PO42 3y ago
  Yes and no. Fundamentally, I agree with you. Nix is hard because it solves an inherently complex problem. But it's also hard because it has some usability flaws. For example, I recently wrote a bunch of Nix and got an error that boiled to me forgetting to add a "name" to a derivation. That is absolutely my bad. However, Nix didn't tell me which file this derivation was in (it said 'unknown file' iirc), the stack trace also wasn't any help . And so I went hunting through the hundreds of lines of Nix I just added to find where I might be missing a "name". Should I have tested my code incrementely? Absolutely, yes! But Nix should also be able to tell me which file I am missing the attribute in. I say all of this as a huge Nix advocate and fan. It's wonderful, it solves so many problems I previously had and I intend to keep using it, but it's far from perfect.
  - jfoutz 3y ago
    Reminds me of in the beginning was the command line. Powerful tools, but they’ll rip your arm off. Learning nix, slowly, really enjoying it though.
  - 3y ago
whateveracct 3y ago
I find Nix to be very usable. People expect to be able to learn things without trying nowadays.
- eternityforest 3y ago
  Most tech these days is designed to learn without trying, so I can see where the expectation would come from. Learn is maybe the wrong word, it's more like "Become familiar", it's such a different experience from trying to learn guitar or drawing or dance or anything in real life that actually requires practice and isn't just mostly the same concepts you already know with different function names
kevincox 3y ago
<quote> 1. Docker Build 2. Docker Run 3. Docker Hub Nix solves the last two. Nix solves packaging your application and its dependencies better than Docker does! </qoute> What am I missing? They just said that Nix solves the last two and the first one better than docker does. > Running your container in a secure, multi-tenant fashion is definitely one of the problems Docker solves Docker does not solve anything related to a secure multi-tenant environment. Docker can provide isolation between mostly trusted parties. Anything running on the same kernel must not be considered securely isolated. So since I'm not getting security anyways running services in Nix is simple and provides the isolation that I care about. Applications aren't going to accidentally break each other or cause dependency hell. I can use UNIX users if I want or even use simple containers like systemd-nspawn. But none of these are secure. I agree that Docker provides nice UX, that is why it won. It made it easy to get something that works and can run fairly reliably across machines. It has flaws, especially reproducibility, but it works and is relatively easy to understand. I sometimes wonder if the Nix stdenv does too much. It is optimized for running configure and make for you but ends up being a lot of complexity that most people don't need with different phases and hooks. If you just use `pkgs.runCommand` you actually get a very simple docker-like experience where you just run commands and copy your build result to the output directory. Plus there is no messing around with build images vs output images to get small results.
- dpc_01234 3y ago
  > I sometimes wonder if the Nix stdenv does too much. Yeah, NixOS is a Linux-based OS, and historically most of the system stuff is C/C++. So `stdenv` is just that - an abstraction for "a standard Linux environment with a working C toolchain to build system packages". I also tend to just use `runCommand` when I can, but even when building things like Rust, Python or JS, quite often there's some little plugin/package that needs to be built with a C compiler, and then `stdenv` comes handy.
1attice 3y ago
(Context: I'm pretty thick into Nix, and have been for about four years. Most of this post is focussed on the NixOS desktop experience, so DevOps nerds, ymmv.) Unpopular opinion: Nix is not that hard. What's "hard" from a nix-promotion strategy is motivating people to understand why they would want the benefits it offers. Mostly because Nix, especially with home-manager, dramatically worsens UX for several day-to-day tasks, simply by violating the Law of Least Surprise every couple of hours in normal use. I want a fully idempotent, version-locked, rewindable user environment, with a version-controlled central config, because I have half a dozen devices that, for reasons, I need to keep perfectly interchangeable with one another. Most users do not want this, for the simple fact that mutating their configs and differentiating them locally on specific machines is not a bug, but a feature. Even more than that, it's an expectation that most software developers share as well. Case in point: I filed a bug against the GitHub CLI last week. If any org has the scope and motivation to build software that's compatible with NixOS, an OS most of whose users are developers, it should be GitHub, which is, at least notionally, all about developers, developers, developers. A change in GH required a config format migration, which was sensibly done by opening the config .yml and rewriting it. Of course, this breaks NixOS not just in practice but in principle. NixOS/home-manager makes config files read-only. Surprise! https://github.com/cli/cli/issues/8462 https://github.com/cli/cli/issues/8462 The response from GitHub was basically, "yeah, we knew this was going to happen, we mentioned it to the packagers at NixOS, but we did it anyway, because it was still the best way to proceed for us." (And they weren't wrong.) Now, once a month is an annoyance, but I run into these problems daily. I can't imagine any sane person -- which I am not -- would persist with using it. Why do I keep using NixOS, then? Because I am terribly and disproprotionately annoyed by small changes in my user experience, which I find disruptive to my workflow and hence threaten my success. For me, forbidding apps from mutating the config files I established for them is a selling point. Being able to version-control an idempotent declarative config for all of them at once is heaven. Unless you're like me, you'll hate NixOS. But some were meant for Nix.
- soraminazuki 3y ago
  Nix is definitely missing a good intro that explains what to expect out of it. That leads to exaggerated comments about its difficulty being copy pasted in just about any related online discussion. But as for the surprise thing though, I think that has more to do with you (presumably) using the unstable branch. Any rolling release distro would cause similar problems. Also for people less familiar with Nix, Nix doesn't force read-only configuration files. Configuration frameworks based on Nix choose to do so most of the time because read-only ones significantly reduces deployment problems compared to read/write ones that can change under your feet any time.
bheadmaster 3y ago
Docker is easy to use because it leverages something that most programmers already know - how to run commands in the shell. Writing a Dockerfile is mostly just figuring out which commands you need to execute, and writing them down. Writing a Nix package is mostly just scratching your head at incomplete documentation, and hanging out at Nix IRC channel hoping someone will help you.
ben0x539 3y ago
Is usability really just one flaw, like, could we get some usability experts to sit down with it for a couple months and then it's perfect?
eternityforest 3y ago
I really really like the idea of idempotent declarative config that eliminates ever having to imperatively touch a server. I really like Nix, it's in fact the only non-debian distro I've liked so far. But Snap+Ansible is Good Enough, until Nix gets usability figured out and it becomes a bit more commonly known.
dpc_01234 3y ago
> I think I understand Nix, too. I don't think so, not from what I'm reading. Not fully. Just comparing with Docker is a sign of limited understanding. Nix is not really a Docker competitor. You can run Nix stuff in a Docker, and it can build you a docker container image as well. Orthogonal. It's just so happen that basic applications of Nix overlap with what Docker is often used for, so comparing the two might seems natural. But Nix is more and more fundamental: Nix is a shared language for software composition. Nix creates a Linux OS for me, prepares custom ISO with my fav. stuff built-in, prepares my home dir, maintains my servers, configures services I use, makes me a dev environment I can share inside my project, future-proofs ad-hoc scripts I wrote, builds me docker containers, builds rpm&debs, makes me cross-compiling toolchains, and so much more. Anyway, Nix does have an usability problem, but it's not fatal. It's not worse than usability of e.g. git, or even usability of Docker. Yeah. Docker. People now consider Docker a bread and butter of SWE, but there are still plenty of people that don't know how to use it, or need lots of help using it, and not much more than 5 years ago you'd have to drag your team and explain to everyone why it's beneficial to use it. And when things go south it takes quite a bit of understanding of the under-the-hood machinery to figure things out. And there are plenty of devs who know like 5 commands to handle git + github UI and when anything goes wrong need help. And people complain about UX of git every week on HN. Usability is 90% familiarity. Once you have enough people who know X well, they help people who don't and live goes on. Once you build a good mental model of Nix, it's actually very simple, elegant, natural and very usable. The error messages and other-UX-stuff sometimes suck, but it's surface level and fixable (thought requires lots of dev work). At this point I can't even imagine working without Nix, and giving up on things it allows me to do. It's really like a super-power. And it's been a great accelerator for teams and project I've introduced it to. I could maybe see something even better just replacing it, but once you really get Nix, there's not going back.
ksjskskskkk 3y ago
in this thread: people who is still learning nix, or people who barely got hooked on nix. and lastly people who looked at nix and didn't like it. absent: everyone who understand the finer details on software packaging and already implemented different trade-offs than nix
anotherhue 3y ago
If everything in the world had to be 'easy' then no one would be able to ride a bicycle or play a violin. Some tools require expertise to master and the pay-off is worth it. I don't go around complaining that violins are too hard. I think of Nix(OS) as a reproducible build system attached to an operating-system linker. It eliminates entire classes of bug reports because (almost) every issue is fully reproducible. If you'd prefer to keep shipping massive binary blobs of gunk around in container images then you have only yourself to blame when things get weird and no one understands what's in the image.

The main thing that made understanding the language much easier was the realization that you arent actually looking at imperative commands. Nix is just a big lazily-evaluated JSON blob. All of the language is just commands to manipulate the values of that JSON. Once you understand that, I think its more straightforward (except some funky syntax like `//`)

hiAndrewQuinn 3y ago
This is how I think of Dhall as well, which I highly recommend. https://dhall-lang.org/ https://dhall-lang.org/
__MatrixMan__ 3y ago
Agreed. For me it helped to think about how modules are composed--something about the order-invariance aspect of it made me understand why this was a good language choice. Suppose you were actually using JSON. You've got X = {a:1, b:2} and Y = {b:3, c:4} In imperative land, if you start with X and then apply Y, "b" will be 3. And if you start with Y and then apply X "b" will be 2. That's bad if you're a package manager, you don't want the order that packages are installed to change their function. The imperative solution is to add some kind of metadata which indicates whether X and Y are compatible, and to consult some kind of solver which prevents you from even trying to do the thing that would create the order-dependence nightmare. But because of how the Nix language works, you never even get to the point where you're clobbering things. Nor do you have to consult a version solver. The fact that you've tried to make "b" both 2 and 3 is a language error. It's as close as you can get to making config errors syntactically invalid and helps you sidestep a whole domain of trouble. It also means that pretty much all problems are code problems, and that's a dimension that we know how to collaborate in. sorta.

anon291 3y ago

Unfortunately if you don't have a pure language, the benefits of nix disappear and you're back in sad imperative land. I'm a nix language fan. The main mistake is lack of typing and debuggability (esp for recursion). The syntax is intuitive

aidenn0 3y ago
I don't think it has to be pure necessarily, but you need some form of lazyness for things to work the way they work now. You could implement it in a non-lazy language by using explicit thunks, but I don't know if that would be better. > The syntax is intuitive Let me guess: you come from a ML or Haskell background?
- anon291 3y ago
  > Let me guess: you come from a ML or Haskell background As a professional computer scientist I am familiar with all the major programming paradigms and all the general syntactic modes, whether that be C-like, Python-like, Ml-like, prolog-like, lisp-like, etc. Yes I have worked professionally as a ML and Haskell programmer but I currently work on Assembler and c++, so my background is equally in both pots. Nix is entirely unsurprising to anyone who is familiar with lambda calculus which should be all computer programmers really. It's fundamental. It'd be like a linguist not knowing what a preposition is.
  - aidenn0 3y ago
    > As a professional computer scientist I am familiar with all the major programming paradigms and all the general syntactic modes, whether that be C-like, Python-like, Ml-like, prolog-like, lisp-like, etc. This is an overly pretentious opening for a comment even for HN. It certainly makes me feel the need to point out that the majority of people on HN (including myself) are most certainly not "professional computer scientists." Neither are users of Docker nor system administrators. Opening your comment this way is implicitly excluding those people from using Nix. > Nix is entirely unsurprising to anyone who is familiar with lambda calculus which should be all computer programmers really. It's fundamental. It'd be like a linguist not knowing what a preposition is. I took my computer science classes from a department that was probably slightly more math-focused than the median CS program. Among those classes was a (optional to non-honors students) 400 level theory of computation class. I don't believe there were more than 2 hours of lecture regarding the lambda calculus, just as an aside that it was an alternate model to Turing Machines and was fully equivalent. We had a single weekly assignment that involved it. I encountered the lambda calculus more in my philosophy classes than in my Computer Science classes. On top of all of that, I know I am not alone in finding many forms of mathematical notation, including the lambda calculus, to be poor notation for writing software.

__MatrixMan__ 3y ago

Something will evolve from that space which doesn't have the flaw. Whether that thing will be called Nix or not, I don't know. I think that means that it's not a fatal flaw, it's just a regular flaw.

jamies 3y ago
I totally agree. I love and hate Nix every day that I use it. I hope that someday they'll make it more user friendly, but I suspect it'll be someone else with a new approach.
- tempay 3y ago
  I struggle to see how another tool will take the spot. I think the power of Nix is that the underpinnings are so pure, academic and well thought out that you can rethink package management in a much cleaner and sane way. Unfortunately that results in the UI not being the priority, though I think the opposite approach results in a conventional package manager with their many flaws and trade offs. I generally think the UI first approach is a better way of building tools, but there are special cases where it doesn’t work due to their being so many edge cases that you need pure underpinnings to make it actually work (e.g. version control).
  - abathur 3y ago
    I feel this. I ~empathize with people who wish it were simpler, and agree there are too many sharp corners. (For example, the traditional CLI certainly left a lot of room for improvement.) I can vaguely imagine the prospect that something new gets this more-right than Nix, but on some level I also suspect most ~complainers aren't appreciating the scale of the domain complexity Nix closes over in order to forge The Nix Way and square decades of contrary software development/packaging/deployment practices with it.
aidenn0 3y ago
I'm not convinced that the upsides of Nix don't necessarily include the downside. Docker files are basically "copy these files in and run these commands with full network access" which is a recipe for both "easy" and "not reproducible" Oh, I need python? "RUN apt-get install -y python" done. Which python version is installed? I don't have to think about that. If you want to ensure the inputs are the same, then you need to impose structure. That structure is a large part of what is confusing with Nix. I hate the Nix language as much as the next-guy, but I don't think that if it were Javascript instead, everyone would be like "oh this is so easy!"

baby 3y ago

My personal take is that functional languages are fine if users don’t have to touch them, but will prevent a product from reaching critical adoption if users are facing them directly.

corethree 3y ago

There needs to be two levels of configuration. One is just straight up a config file and the other is the nix language. Average users should not need to ever touch the nix language. They should only touch a config file. This config file needs to be so simple that it Can be configured with a GUI. Isomorphic configs when run with a formatter should come out identical. What I mean by this is if you have a machine with say version 3.123 of an app installed there is only one possible config file that can describe this configuration. There shouldn't be 50 possible ways to program that same configuration.

Niksko 3y ago
It's not quite the same, but Home Manager feels a little like what you're describing.
- corethree 3y ago
  Never used it, it's been a bit since I used nixos. Still I'm sure there's a lot of warts.
- aidenn0 3y ago
  Home Manager is literally the opposite of what they are describing.
Cyph0n 3y ago
This is exactly the goal behind NixOS the Linux distro (the worst part about Nix is the naming!). The distro itself and module authors give you high-level building blocks that allow you to configure the system declaratively (e.g., create users) as well as install & configure software. Of course, you still need to write Nix to use these options and modules. But if you take a NixOS configuration and apply it on a different machine, it should do exactly the same thing (modulo hardware-specific config options). I am a relatively recent NixOS convert and I quickly decided that I will be using it exclusively on my personal servers going forward. I even wrote a tool that simplifies migrating Docker Compose stacks to NixOS: https://github.com/aksiksi/compose2nix https://github.com/aksiksi/compose2nix

_8j50 3y ago

Personally it's harder to reason about systems where you define the desired state and it magically happens, this includes functional languages. I have no idea why people think that is better. I always want to command the system and be able to understand the processes it will undergo to implement that change. Even if it is reliable, it's difficult to understand or be confident in a system whose inner workings feel like a black-box.

eternityforest 3y ago
I've always been pretty comfortable with black boxes, as long as they're repeatable and have fewer bugs than I would expect to produce by hand. I wonder if it has to do with mastering a real life skill before learning to code, if you can draw or play an instrument well maybe it sets you up for more of a direct action mindset?
- _8j50 3y ago
  I think it has more to do with desiring control. Black boxes feel like out of control. I can reason about how transport vehicles work for example but if there was a quantum teleport machine that only wants my destination and I get magically zapped there, it would be amazing but plenty of people including me would have a hard time trusting it fully because we can't have an intuitive understanding of how it works (cars,trains = wheels go round and round lol).
dqv 3y ago
I mean anything new that I'm experiencing for the first time is magic because I don't understand how it works. Perl was magic until I learned what the weird syntax meant. I've learned a little about Java over the years and so it seems less magical, but there still seems to be a lot of magic I can't comprehend. I think the issue is that Nix is "too much new", not too much magic. Because I have familiarity with Nix, I can go to e.g. the PostgreSQL build file [0] and mostly make sense of what's going on, just like any other language I'm familiar with. Now if you give me something like a debian package, I have no idea WTF is going on. If anything goes wrong with a package installation, there isn't much I can do, except try to build outside the package manager. With Nix, I have a few options, from simply overriding the upstream repository to forking the broken module to fix whatever problems I'm having. It's also really nice to be able to be confident that what is in the Nix file is what's in my environment. As the syntax and libraries became more familiar, so did my confidence using Nix. That's pretty much how it works with most things, I think. [0]: https://github.com/NixOS/nixpkgs/blob/203ecda835bcf69633df7183459283543dd4a874/pkgs/servers/sql/postgresql/default.nix https://github.com/NixOS/nixpkgs/blob/203ecda835bcf69633df71...

Niksko 3y ago

My biggest frustration with Nix is the lack of typing. Writing anything more than the basics, I feel like I quickly run into an issue of not being able to reason easily about what structures I'm manipulating, and I haven't gotten very far by trying to lean on the editor I'm using either.

abathur 3y ago
There's some prospect of Nickel (https://github.com/tweag/nickel https://github.com/tweag/nickel) meeting this need, though haven't tried it and can't really vouch. Typing might be really helpful for building your own layers up, but I don't know if it can meaningfully help with problems around consuming existing Nix ~APIs.
- evanjrowley 3y ago
  Another new contender in the typed Nix space if Garn, which allows one to interact with Nix via TypeScript: https://news.ycombinator.com/item?id=38112416 https://news.ycombinator.com/item?id=38112416
wharvle 3y ago
Same. At this point I've resolved I'm never again writing in a language without static typing, unless someone's paying me to. Too much of a headache.

gipp 3y ago

It's not exactly a 1:1 comparison, but NixOS' tight and extremely simple integration with systemd and podman has made NixOS native containers a pleasure to work with. OP seems to maybe not be aware of them?

noelwelsh 3y ago

Comments here arguing about functional languages etc. really miss the point from my experience. The usability issues for me were: - The Nix homepage didn't explain the actual benefit of using Nix. - Different introductions recommending vastly different ways of getting started. E.g. flakes vs non-flakes. Even now, the homepage is bad: > Nix is a tool that takes a unique approach to package management and system configuration. Learn how to make reproducible, declarative and reliable systems. First sentence tells me nothing. Second sentence doesn't differentiate it from Docker. This is, I believe, the fatal flaw of Nix: the developers just don't get how to present something that is accessible to users who are not deeply invested in the system. I don't care what language Nix is written in. I understand it's bad for various reasons (and I'm a fan of programming languages and I would probably agree with the reasons) but as a user I just want the equivalent of installing software, configuring it, and rolling back if things are messed up. If I can't do that in a few expressions or commands or whatever, I'm not interested. I don't care about flakes vs whatever. In fact I don't care about flakes at all. I want to type `nix do-the-thing-I-am-actually-interested-in` and have it Just Work.

puzzledobserver 3y ago
I tend to agree. I am comfortable with writing functional programs, but I have tried and failed multiple times to grok the Nix documentation. The complexity is not because "functional programming is hard", but because the documentation is terrible. To get me started with Nix, the documentation needs just a few things: 1. Internal consistency: A large fraction of the documentation is spent talking about how great flakes are, with a (last time I checked) big disclaimer at the top saying that flakes are experimental. Another fraction of the documentation talks about how great declarative installations are, while the third happily uses nix-env which, on the surface, seems no different from [apt / dnf] install. 2. How to use the package manager, for dummies. The last time I tried to install NixOS, I tried to install Z3 and its Java bindings, but got completely lost with the "also install the Java bindings" part. I'd rather just spin up a Docker container with my favorite distribution, and put my trusty magic installations there. 3. How to use Nix the language, for dummies. For people wanting to understand the system better than the dummies from part 2. I remember some magic ellipsis, and remaining confused about what they're about. 4. Really what Nix the language is about, for non-dummies. The documentation currently conflates the last three points, and is internally inconsistent. It is also not clear where users can turn to for help. And then, I install Silverblue on my machine, and for the most part it is rock solid and easy-to-use. Sure, there are some installation commands that I need to run at the beginning of time, but I can put those in a script, and there's my nearly declarative install.

sconi 3y ago

I get very similar vibes to early Docker as I do about Nix today: it requires doing things very differently, is difficult ramp up on because of that, but those who pay the cost to invest the time are gaining an advantage now by their ability to do dazzling things by adopting early.

Avshalom 3y ago
What dazzling things is docker facilitating? kinda just thought it was marginally decreasing sys-admin/op-management costs.
- sconi 3y ago
  Back in Docker's day it was (basically) the only thing out there that let you reliably package up an application in a portable way from any Linux distribution to any Linux distribution - before Docker it was prohibitively difficult to build your application on your Ubuntu desktop and run it on your CentOS servers because you had to wrangle system packaging, library differences, and see the app run in the same way as it would in production. Docker turned the runtime into one consistent thing everywhere (and the ability to ship it to the deployment target). That's less novel in 2023 but solved serious problems a decade ago. In 2023 reproducible builds are important as reflected by efforts like Debian's reproducible builds or SALSA and nix zooms way beyond that to solve downstream problems, too
  - Avshalom 3y ago
    Speaking as a linux user since 2004: it absolutely was not "prohibitively difficult" as shown by every application pre-docker. Beyond that, it's hardly dazzling
- wharvle 3y ago
  It lets me run up-to-date daemons on my home server, with excellent uptime, on some old-ass version of Debian I never bother to update (don't worry, it's not routable from the public Internet) and without having to touch systemd (or sysv init, or openrc, or whatever), having written nothing but a single short shell script for each service. I could take all my exact same knowledge and scripts (and a backup of the data directories, helpfully and completely documented in those same shell scripts) and spin my whole stack up again on basically any other distro, only having to google what installing Docker looks like for that system. Different init system? Older/newer packages than I want in the distro's official repos? Some futzing-about with third party repos needed to add to get what I want at a version that's not three years old? No option but downloading a tarball and dicking around with that, on this distro? Package on this distro stores some daemon's config in a different places from the last one, and carves it up differently, so you can't just drop in your old config and have it work? This distro or version puts data for this daemon somewhere different, so now your backup scripts are fucked? I don't have to care at all. About any of that. I no longer have to give any shits which distro or version my home server's on (within reason) and anything I learn managing it transfers basically anywhere. I can turn around and immediately apply nearly 100% of that skillset to any day-job I've had in the last decade or so.

smilliken 3y ago

Nix is hard in the way that programming is hard. Not everyone gets over the activation energy to be successful. The ones that do don't regret the effort. Nix is complex because the problems it solves are high complexity problems that other systems don't solve. Docker is not a substitute for Nix. The solution isn't to use a weaker tool, because the weaker tool doesn't solve your problem. It's not uncommon to see a programmer use a spreadsheet, but you wouldn't expect to see a programmer use a spreadsheet where a database is needed. And you don't see people trying to use garbage-collected languages to write operating systems, even though they are easier to use than C. It's perhaps inefficient when a tool is too powerful for what you need, but it's a fatal flaw if the tool you use is too weak for what you need. Nix let's you control your dependencies in a way no other tool even attempts. I can pin and patch any combination of dependencies, even conflicting ones in single environment, with reproducible builds— I'm in control of every detail. I would never consider a downgrade from that, but I'm open to upgrades if something even more capable came along.

Cu3PO42 3y ago
Yes and no. Fundamentally, I agree with you. Nix is hard because it solves an inherently complex problem. But it's also hard because it has some usability flaws. For example, I recently wrote a bunch of Nix and got an error that boiled to me forgetting to add a "name" to a derivation. That is absolutely my bad. However, Nix didn't tell me which file this derivation was in (it said 'unknown file' iirc), the stack trace also wasn't any help . And so I went hunting through the hundreds of lines of Nix I just added to find where I might be missing a "name". Should I have tested my code incrementely? Absolutely, yes! But Nix should also be able to tell me which file I am missing the attribute in. I say all of this as a huge Nix advocate and fan. It's wonderful, it solves so many problems I previously had and I intend to keep using it, but it's far from perfect.
- jfoutz 3y ago
  Reminds me of in the beginning was the command line. Powerful tools, but they’ll rip your arm off. Learning nix, slowly, really enjoying it though.
- 3y ago

whateveracct 3y ago

I find Nix to be very usable. People expect to be able to learn things without trying nowadays.

eternityforest 3y ago
Most tech these days is designed to learn without trying, so I can see where the expectation would come from. Learn is maybe the wrong word, it's more like "Become familiar", it's such a different experience from trying to learn guitar or drawing or dance or anything in real life that actually requires practice and isn't just mostly the same concepts you already know with different function names

kevincox 3y ago

<quote> 1. Docker Build 2. Docker Run 3. Docker Hub Nix solves the last two. Nix solves packaging your application and its dependencies better than Docker does! </qoute> What am I missing? They just said that Nix solves the last two and the first one better than docker does. > Running your container in a secure, multi-tenant fashion is definitely one of the problems Docker solves Docker does not solve anything related to a secure multi-tenant environment. Docker can provide isolation between mostly trusted parties. Anything running on the same kernel must not be considered securely isolated. So since I'm not getting security anyways running services in Nix is simple and provides the isolation that I care about. Applications aren't going to accidentally break each other or cause dependency hell. I can use UNIX users if I want or even use simple containers like systemd-nspawn. But none of these are secure. I agree that Docker provides nice UX, that is why it won. It made it easy to get something that works and can run fairly reliably across machines. It has flaws, especially reproducibility, but it works and is relatively easy to understand. I sometimes wonder if the Nix stdenv does too much. It is optimized for running configure and make for you but ends up being a lot of complexity that most people don't need with different phases and hooks. If you just use `pkgs.runCommand` you actually get a very simple docker-like experience where you just run commands and copy your build result to the output directory. Plus there is no messing around with build images vs output images to get small results.

dpc_01234 3y ago
> I sometimes wonder if the Nix stdenv does too much. Yeah, NixOS is a Linux-based OS, and historically most of the system stuff is C/C++. So `stdenv` is just that - an abstraction for "a standard Linux environment with a working C toolchain to build system packages". I also tend to just use `runCommand` when I can, but even when building things like Rust, Python or JS, quite often there's some little plugin/package that needs to be built with a C compiler, and then `stdenv` comes handy.

1attice 3y ago

(Context: I'm pretty thick into Nix, and have been for about four years. Most of this post is focussed on the NixOS desktop experience, so DevOps nerds, ymmv.) Unpopular opinion: Nix is not that hard. What's "hard" from a nix-promotion strategy is motivating people to understand why they would want the benefits it offers. Mostly because Nix, especially with home-manager, dramatically worsens UX for several day-to-day tasks, simply by violating the Law of Least Surprise every couple of hours in normal use. I want a fully idempotent, version-locked, rewindable user environment, with a version-controlled central config, because I have half a dozen devices that, for reasons, I need to keep perfectly interchangeable with one another. Most users do not want this, for the simple fact that mutating their configs and differentiating them locally on specific machines is not a bug, but a feature. Even more than that, it's an expectation that most software developers share as well. Case in point: I filed a bug against the GitHub CLI last week. If any org has the scope and motivation to build software that's compatible with NixOS, an OS most of whose users are developers, it should be GitHub, which is, at least notionally, all about developers, developers, developers. A change in GH required a config format migration, which was sensibly done by opening the config .yml and rewriting it. Of course, this breaks NixOS not just in practice but in principle. NixOS/home-manager makes config files read-only. Surprise! https://github.com/cli/cli/issues/8462 https://github.com/cli/cli/issues/8462 The response from GitHub was basically, "yeah, we knew this was going to happen, we mentioned it to the packagers at NixOS, but we did it anyway, because it was still the best way to proceed for us." (And they weren't wrong.) Now, once a month is an annoyance, but I run into these problems daily. I can't imagine any sane person -- which I am not -- would persist with using it. Why do I keep using NixOS, then? Because I am terribly and disproprotionately annoyed by small changes in my user experience, which I find disruptive to my workflow and hence threaten my success. For me, forbidding apps from mutating the config files I established for them is a selling point. Being able to version-control an idempotent declarative config for all of them at once is heaven. Unless you're like me, you'll hate NixOS. But some were meant for Nix.

soraminazuki 3y ago
Nix is definitely missing a good intro that explains what to expect out of it. That leads to exaggerated comments about its difficulty being copy pasted in just about any related online discussion. But as for the surprise thing though, I think that has more to do with you (presumably) using the unstable branch. Any rolling release distro would cause similar problems. Also for people less familiar with Nix, Nix doesn't force read-only configuration files. Configuration frameworks based on Nix choose to do so most of the time because read-only ones significantly reduces deployment problems compared to read/write ones that can change under your feet any time.

bheadmaster 3y ago

Docker is easy to use because it leverages something that most programmers already know - how to run commands in the shell. Writing a Dockerfile is mostly just figuring out which commands you need to execute, and writing them down. Writing a Nix package is mostly just scratching your head at incomplete documentation, and hanging out at Nix IRC channel hoping someone will help you.

ben0x539 3y ago

Is usability really just one flaw, like, could we get some usability experts to sit down with it for a couple months and then it's perfect?

eternityforest 3y ago

I really really like the idea of idempotent declarative config that eliminates ever having to imperatively touch a server. I really like Nix, it's in fact the only non-debian distro I've liked so far. But Snap+Ansible is Good Enough, until Nix gets usability figured out and it becomes a bit more commonly known.

dpc_01234 3y ago

> I think I understand Nix, too. I don't think so, not from what I'm reading. Not fully. Just comparing with Docker is a sign of limited understanding. Nix is not really a Docker competitor. You can run Nix stuff in a Docker, and it can build you a docker container image as well. Orthogonal. It's just so happen that basic applications of Nix overlap with what Docker is often used for, so comparing the two might seems natural. But Nix is more and more fundamental: Nix is a shared language for software composition. Nix creates a Linux OS for me, prepares custom ISO with my fav. stuff built-in, prepares my home dir, maintains my servers, configures services I use, makes me a dev environment I can share inside my project, future-proofs ad-hoc scripts I wrote, builds me docker containers, builds rpm&debs, makes me cross-compiling toolchains, and so much more. Anyway, Nix does have an usability problem, but it's not fatal. It's not worse than usability of e.g. git, or even usability of Docker. Yeah. Docker. People now consider Docker a bread and butter of SWE, but there are still plenty of people that don't know how to use it, or need lots of help using it, and not much more than 5 years ago you'd have to drag your team and explain to everyone why it's beneficial to use it. And when things go south it takes quite a bit of understanding of the under-the-hood machinery to figure things out. And there are plenty of devs who know like 5 commands to handle git + github UI and when anything goes wrong need help. And people complain about UX of git every week on HN. Usability is 90% familiarity. Once you have enough people who know X well, they help people who don't and live goes on. Once you build a good mental model of Nix, it's actually very simple, elegant, natural and very usable. The error messages and other-UX-stuff sometimes suck, but it's surface level and fixable (thought requires lots of dev work). At this point I can't even imagine working without Nix, and giving up on things it allows me to do. It's really like a super-power. And it's been a great accelerator for teams and project I've introduced it to. I could maybe see something even better just replacing it, but once you really get Nix, there's not going back.

ksjskskskkk 3y ago

in this thread: people who is still learning nix, or people who barely got hooked on nix. and lastly people who looked at nix and didn't like it. absent: everyone who understand the finer details on software packaging and already implemented different trade-offs than nix

anotherhue 3y ago

If everything in the world had to be 'easy' then no one would be able to ride a bicycle or play a violin. Some tools require expertise to master and the pay-off is worth it. I don't go around complaining that violins are too hard. I think of Nix(OS) as a reproducible build system attached to an operating-system linker. It eliminates entire classes of bug reports because (almost) every issue is fully reproducible. If you'd prefer to keep shipping massive binary blobs of gunk around in container images then you have only yourself to blame when things get weird and no one understands what's in the image.