NixOS has one fatal flaw(changelog.com)
changelog.com
NixOS has one fatal flaw
https://changelog.com/posts/nixos-fatal-flaw
77 comments
PNPM (a package manager for JavaScript/NPM ecosystem) does this with much better usability:
> 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
It does so with much lower user facing complexity than Nix. I like flakes because they’re trying to follow a similar model, but still quite hard to teach newcomers:
- The CLI should literally have the same verbs as PNPM, but needs a bunch of complicated flags to do the same actions.
- The nix expression language is intimidating and has kinda bad tooling out of the box. I would love to use Starlark/Python/Typescript instead. Even Guix’s scheme language is more appealing to me, although Guix is too niche and GNU focused to be practical.
- Nix package files evaluate down to configuration for the Nix package manager, but I haven’t ever seen a good explanation for the basic essentials underneath all the abstraction. Every guide I’ve learned from and all the package defs I’ve read seem to cargo cult many layers of mysterious config composing config. Without easy to learn essentials it’s difficult to grok the system as a whole.
I would love to adopt Nix for developer tooling for Notion’s engineers, but today it’s about infinity times easier to work around the limitations mentioned of Docker+Ubuntu+NPM than to work around the limitations of 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
It does so with much lower user facing complexity than Nix. I like flakes because they’re trying to follow a similar model, but still quite hard to teach newcomers:
- The CLI should literally have the same verbs as PNPM, but needs a bunch of complicated flags to do the same actions.
- The nix expression language is intimidating and has kinda bad tooling out of the box. I would love to use Starlark/Python/Typescript instead. Even Guix’s scheme language is more appealing to me, although Guix is too niche and GNU focused to be practical.
- Nix package files evaluate down to configuration for the Nix package manager, but I haven’t ever seen a good explanation for the basic essentials underneath all the abstraction. Every guide I’ve learned from and all the package defs I’ve read seem to cargo cult many layers of mysterious config composing config. Without easy to learn essentials it’s difficult to grok the system as a whole.
I would love to adopt Nix for developer tooling for Notion’s engineers, but today it’s about infinity times easier to work around the limitations mentioned of Docker+Ubuntu+NPM than to work around the limitations of Nix.
Garn [0] is most of that: simpler CLI, and Typescript for configuration, though lying on top of Nix.
(Disclaimer: I work on garn)
[0] https://github.com/garnix-io/garn
(Disclaimer: I work on garn)
[0] https://github.com/garnix-io/garn
I looked at the docs, and it seems promising but I’d like to do something like: `garn add --dev [email protected]` and have git added at the given version as a dev tool. With config-as-code, is it possible?
I don't think you can ever get Nix as simple as PNPM, simply because native libraries are sometimes annoying, need to be configured at build time to a greater degree and because the problem space it attacks is so much larger than PNPM, which only deals with the JS/Node.js ecosystem.
However, I do think that there exist reasonable levels of abstraction that sacrifice some expressive power for simplicity and such systems could maybe expose a PNPM-like CLI. One example that comes to mind is devenv.nix [1]. While it doesn't yet have a CLI, its configuration file is YAML and relatively simple. I think there's more to be done in this space and I hope for tools that are easier to grasp in the future.
> Nix package files evaluate down to configuration for the Nix package manager, but I haven’t ever seen a good explanation for the basic essentials underneath all the abstraction. Every guide I’ve learned from and all the package defs I’ve read seem to cargo cult many layers of mysterious config composing config. Without easy to learn essentials it’s difficult to grok the system as a whole.
To me it sounds like the essential that you're referring to is the 'derivation' primitive, which is almost always hidden behind the mkDerivation abstraction from nixpkgs. This [2] blog post is an exploration of what exactly that means.
I'd also love for the documentation situation to be much better, in particular in terms of official, curated resources. But I'm not convinced that you actually need to know the difference between derivation and mkDerivation to make effective use of Nix, because in practice you would always use the latter. That said, mkDerivation and the whole of nixpkgs is essentially a huge DSL (I believe this is what you meant when you said 'config composing config') that you do need to know and is woefully underdocumented.
> I would love to adopt Nix for developer tooling for Notion’s engineers, but today it’s about infinity times easier to work around the limitations mentioned of Docker+Ubuntu+NPM than to work around the limitations of Nix.
One approach I have taken to is to specify the environment in Nix, but then generate Docker devcontainers from it, so most people don't come into contact with Nix if they don't want to.
[1] https://devenv.sh
[2] https://ianthehenry.com/posts/how-to-learn-nix/derivations/
However, I do think that there exist reasonable levels of abstraction that sacrifice some expressive power for simplicity and such systems could maybe expose a PNPM-like CLI. One example that comes to mind is devenv.nix [1]. While it doesn't yet have a CLI, its configuration file is YAML and relatively simple. I think there's more to be done in this space and I hope for tools that are easier to grasp in the future.
> Nix package files evaluate down to configuration for the Nix package manager, but I haven’t ever seen a good explanation for the basic essentials underneath all the abstraction. Every guide I’ve learned from and all the package defs I’ve read seem to cargo cult many layers of mysterious config composing config. Without easy to learn essentials it’s difficult to grok the system as a whole.
To me it sounds like the essential that you're referring to is the 'derivation' primitive, which is almost always hidden behind the mkDerivation abstraction from nixpkgs. This [2] blog post is an exploration of what exactly that means.
I'd also love for the documentation situation to be much better, in particular in terms of official, curated resources. But I'm not convinced that you actually need to know the difference between derivation and mkDerivation to make effective use of Nix, because in practice you would always use the latter. That said, mkDerivation and the whole of nixpkgs is essentially a huge DSL (I believe this is what you meant when you said 'config composing config') that you do need to know and is woefully underdocumented.
> I would love to adopt Nix for developer tooling for Notion’s engineers, but today it’s about infinity times easier to work around the limitations mentioned of Docker+Ubuntu+NPM than to work around the limitations of Nix.
One approach I have taken to is to specify the environment in Nix, but then generate Docker devcontainers from it, so most people don't come into contact with Nix if they don't want to.
[1] https://devenv.sh
[2] https://ianthehenry.com/posts/how-to-learn-nix/derivations/
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.
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.
FWIW, Nickel is one attempt from the Nix community at creating a Nix-like language with static typing, as well as better error reporting I believe:
https://nickel-lang.org
As far as more loosely related technology, there's also https://cuelang.org, which is... something different.
https://nickel-lang.org
As far as more loosely related technology, there's also https://cuelang.org, which is... something different.
I'm rooting for Nickel, I really am, but I am doubtful. Nix is so incredibly dynamic that I believe it's nearly impossible to give it a practical static type system. I say practicaly because I do believe it is possible to come up with a reasonable type system, it's just that it would be so complicated to use that hardly anyone actually would outside of extremely specific applications (see Agda, Idris, ...).
In order to get something more reasonable, I think we would also need to rethink both the NixOS module and nixpkgs DSLs. Which is of course possible, but such a momentous task that I don't see it gaining much traction.
I think it's more realistic, and maybe even sufficient to integrate better error reporting into Nix itself. This is surely also no easy feat, but I am confident some improvements could be made: for example, more acurate tracking of source locations.
And while I almost always prefer static over dynamic typing, writing a specific NixOS config feels like it's one of the moments where it's less important, because I don't care about all possible executions working, I just need my specific config to work. This all changes once you write your own modules, where you obviously want all configurations to work, but that is less important for end user adoption IMO.
In order to get something more reasonable, I think we would also need to rethink both the NixOS module and nixpkgs DSLs. Which is of course possible, but such a momentous task that I don't see it gaining much traction.
I think it's more realistic, and maybe even sufficient to integrate better error reporting into Nix itself. This is surely also no easy feat, but I am confident some improvements could be made: for example, more acurate tracking of source locations.
And while I almost always prefer static over dynamic typing, writing a specific NixOS config feels like it's one of the moments where it's less important, because I don't care about all possible executions working, I just need my specific config to work. This all changes once you write your own modules, where you obviously want all configurations to work, but that is less important for end user adoption IMO.
I had thought the Nix 'language' was just a way to describe packages, dependencies and configs, more a config format than a language. Why would it need static typing?
Man i can't wait for Nickel to work with Nix. Feels impossibly difficult though.
I often think that making Nix logic + configuration is just a mistake. I kinda feel like i'd prefer something that output a JSON-like config, and that config was a deterministic instruction for my stuff.
I know why that sounds impossible or big or difficult or etc. but as a user, i often am writing something that walks and talks almost and so damn close to JSON. Most of it looks like simple configuration. But can i print a damn JSON object? Hell no. Because there's lazy function calls all over the place.
They managed to make something (and other similar langs) that looks like clean readable configuration, but acts like some obtuse bespoke logic where you can't know what anything is without running it - and running it to see output is weirdly difficult.
I am on Nix, but i kinda think there's more than one fatal flaw. I adore what they've done, but there has to be something better and more enjoyable as a system configuration.. i hope.
It's probably a tooling problem. I get that. But still.. i just want to see some configuration output. Why is that so hard?
I often think that making Nix logic + configuration is just a mistake. I kinda feel like i'd prefer something that output a JSON-like config, and that config was a deterministic instruction for my stuff.
I know why that sounds impossible or big or difficult or etc. but as a user, i often am writing something that walks and talks almost and so damn close to JSON. Most of it looks like simple configuration. But can i print a damn JSON object? Hell no. Because there's lazy function calls all over the place.
They managed to make something (and other similar langs) that looks like clean readable configuration, but acts like some obtuse bespoke logic where you can't know what anything is without running it - and running it to see output is weirdly difficult.
I am on Nix, but i kinda think there's more than one fatal flaw. I adore what they've done, but there has to be something better and more enjoyable as a system configuration.. i hope.
It's probably a tooling problem. I get that. But still.. i just want to see some configuration output. Why is that so hard?
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.
Powerful tools, but they’ll rip your arm off.
Learning nix, slowly, really enjoying it though.
Yeah in many ways, Nix is a research project that escaped the lab. It’s the first tool of its kind that also happened to become successful. You have to write in this dynamically typed Haskell with poor affordances for being a build system and fragmented ways of addressing pinning.
I recognize this argument, but eventually it just becomes a wall of difficulty for people. I see the same problem with Gradle and Bazel. There's just something to be said about the work required to abstract fundamentally complex concepts into a simple and grokkable API that these systems just don't manage to get right.
[deleted]
People generally want to program to accomplish goals, and they want to minimize the amount of setup time and yak-shaving needed to start working on those goals.
Nix does solve a lot of complex problems and gives you a lot of control over your dependencies. But if the complexity to start using Nix for your project is too high, then you're going to opt for a less powerful solution that lets you get stuff done.
I say this as someone who really loves Nix and the power it provides -- the UX is a huge challenge for adoption. It's better to confront that fact if we want Nix to succeed.
Nix does solve a lot of complex problems and gives you a lot of control over your dependencies. But if the complexity to start using Nix for your project is too high, then you're going to opt for a less powerful solution that lets you get stuff done.
I say this as someone who really loves Nix and the power it provides -- the UX is a huge challenge for adoption. It's better to confront that fact if we want Nix to succeed.
I like the idea of Nix, but I quickly moved on after a few days of testing. Mostly because I just don't have a use case for the stronger tools.
On Ubuntu you can make something work, then ship it in a box and it works anywhere, with some sandboxing. What more would I want?
Reproducible builds are nice, but I don't currently do any significant compiled language work aside from embedded.
On Ubuntu you can make something work, then ship it in a box and it works anywhere, with some sandboxing. What more would I want?
Reproducible builds are nice, but I don't currently do any significant compiled language work aside from embedded.
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.
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.
> 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.
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.
(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
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.
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
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.
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.
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.
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.
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.
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.
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.
This is completely trivial to do in Nix now. Whoever's writing the nix can just expose "simple" config as a JSON file and use those values whatever.
It needs to be made a standard and enforced programmatically.
If thousands of users aren't following it, what's the point? Now the OS has to cater to the requirements of all those users.
If thousands of users aren't following it, what's the point? Now the OS has to cater to the requirements of all those users.
Having a standardized system for that only makes Nix more complicated, not less. Now you have two parallel configuration systems to worry about. And the "simple" one will inevitably accrue more and more features to address its lack of flexibility. That's like the first law of config languages.
Now you inexplicably have two parallel configuration systems to do one thing
It exists for all software that has configuration and has a plugin system.
Think games. If I'm playing a game and I want to change the configuration to easy mode and up the resolution to wide screen I need to write a program or script to do it? No it should be a dumb setting configurable via gui.
If I want to modify a game beyond the dumb config or modify the config itself then scripts make sense. It's called mods. In games and in software with plugins, configs and scripts live side by side. It's one of the most common patterns in the world.
Additionally you're not seeing what I'm proposing here.
All configs and packages have to go through the "dumb" system. There is zero alternative. This is exactly what games do.
If you want to modify the configs then you go through the modding system. This can use the nix language.
Either way as it exists right now nix can't have a GUI for its config. If I make changes on a GUI how does the program know how to modify your config file which is a custom script that you could of wrote in a thousand different ways? It can't. You want a GUI, you need a dumb config, end of story. Unless you want nix stuck in the niche group of power users you need a GUI.
Think games. If I'm playing a game and I want to change the configuration to easy mode and up the resolution to wide screen I need to write a program or script to do it? No it should be a dumb setting configurable via gui.
If I want to modify a game beyond the dumb config or modify the config itself then scripts make sense. It's called mods. In games and in software with plugins, configs and scripts live side by side. It's one of the most common patterns in the world.
Additionally you're not seeing what I'm proposing here.
All configs and packages have to go through the "dumb" system. There is zero alternative. This is exactly what games do.
If you want to modify the configs then you go through the modding system. This can use the nix language.
Either way as it exists right now nix can't have a GUI for its config. If I make changes on a GUI how does the program know how to modify your config file which is a custom script that you could of wrote in a thousand different ways? It can't. You want a GUI, you need a dumb config, end of story. Unless you want nix stuck in the niche group of power users you need a GUI.
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
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
No. Because the nix language is an actual programming language you can have hundreds or millions of programs that can be interpreted into identical configurations. It makes it so that these configuration files can get unreadable.
I worked at a company where ALL development happened on a nixos development configuration that was shared by the entire company. So all developers were developing on essentially the same configuration as the deployment machine. But the nix stuff started getting unwieldy and complicated. Just adding a freaking package was a programming chore.
The only way it worked was because this company was big enough to have a team dedicated to NixOS. Right an entire team just managing NixOS and this is NOT the team that runs dev ops of ops in general. That's how complicated it is.
Anyway the fact that you have to program the configuration makes it hard to use, it makes it hard to build a GUI around the configuration. Imagine you're playing a video game and the video game required you to write python code to configure it.
That would be a dumb design. The python code could be for modding it, that makes sense but you still need a configuration layer that's much more declarative and dumb. You can have this dumb layer STILL have all the properties of Nix. And you can still have the nix language underneath the dumb configuration layer for users who want to create packages and stuff like that.
If the nix developers worked on this and got GUI up, I'm telling you user adoption will sky rocket. Suddenly you'll get more casual users willing to use it as their daily driver OS. And you'll get more advanced users too because these casual users are more easily converted to advanced users due to the more gradual learning curve.
I worked at a company where ALL development happened on a nixos development configuration that was shared by the entire company. So all developers were developing on essentially the same configuration as the deployment machine. But the nix stuff started getting unwieldy and complicated. Just adding a freaking package was a programming chore.
The only way it worked was because this company was big enough to have a team dedicated to NixOS. Right an entire team just managing NixOS and this is NOT the team that runs dev ops of ops in general. That's how complicated it is.
Anyway the fact that you have to program the configuration makes it hard to use, it makes it hard to build a GUI around the configuration. Imagine you're playing a video game and the video game required you to write python code to configure it.
That would be a dumb design. The python code could be for modding it, that makes sense but you still need a configuration layer that's much more declarative and dumb. You can have this dumb layer STILL have all the properties of Nix. And you can still have the nix language underneath the dumb configuration layer for users who want to create packages and stuff like that.
If the nix developers worked on this and got GUI up, I'm telling you user adoption will sky rocket. Suddenly you'll get more casual users willing to use it as their daily driver OS. And you'll get more advanced users too because these casual users are more easily converted to advanced users due to the more gradual learning curve.
I disagree. I've been a linux user for 20 years now and for the first 18 I never fixed a package. I've been a NixOS user for 2 years and suddenly I'm a participant. Having a common language removes a lot of barriers that otherwise prevent people from contributing.
As for the language itself it's... fine. Most alternatives that get proposed don't have anything like a recursive attribute set, which is something that matches the problem domain very well.
As for the language itself it's... fine. Most alternatives that get proposed don't have anything like a recursive attribute set, which is something that matches the problem domain very well.
>I disagree. I've been a linux user for 20 years now and for the first 18 I never fixed a package. I've been a NixOS user for 2 years and suddenly I'm a participant.
That's the problem. Most people and developers don't want to be a "participant". They need something that gets the job done. Your disagreement represents a niche and if the devs cater to your disagreement then they cater to a small niche.
The best design caters to both the average more casual user and the more advanced user. Many developers want a computer that just works so they can concentrate on development, that's why most developers own macs even though linux is the most hacker friendly OS. NixOS especially forces users to "participate" in in-depth OS configuration which is not desired by the majority.
People in the linux world need to be empathetic with the more common user otherwise their part of the world will remain niche and closed source operating systems like windows will be leaps and bounds ahead of linux in terms of usability and user friendliness.
Linux has made lots of strides in the last decade, but for user friendliness? It has ALSO made big strides here. But not NixOS. NixOS is a step backwards for the average user and a step forward for someone like you or me who's willing to learn a completely new programming language to use an operating system.
I'm a functional programmer so ML style languages like Nix are trivial to me and easy to learn and easy to understand. But this ability doesn't make me blind and lose empathy for the average user and even the average developer who doesn't like haskell or ML.
More OSS people need to understand this. My comment here wasn't about what I wanted. When I used NixOS everything was just fine. I had no problems with it from the standpoint you describe as a personal OS. But I was still able to identifiy the problem with NixOS as a consumer product or even as a product used at a company for development. This isn't a trivial problem. It's a major impediment that hinders adoption.
That's the problem. Most people and developers don't want to be a "participant". They need something that gets the job done. Your disagreement represents a niche and if the devs cater to your disagreement then they cater to a small niche.
The best design caters to both the average more casual user and the more advanced user. Many developers want a computer that just works so they can concentrate on development, that's why most developers own macs even though linux is the most hacker friendly OS. NixOS especially forces users to "participate" in in-depth OS configuration which is not desired by the majority.
People in the linux world need to be empathetic with the more common user otherwise their part of the world will remain niche and closed source operating systems like windows will be leaps and bounds ahead of linux in terms of usability and user friendliness.
Linux has made lots of strides in the last decade, but for user friendliness? It has ALSO made big strides here. But not NixOS. NixOS is a step backwards for the average user and a step forward for someone like you or me who's willing to learn a completely new programming language to use an operating system.
I'm a functional programmer so ML style languages like Nix are trivial to me and easy to learn and easy to understand. But this ability doesn't make me blind and lose empathy for the average user and even the average developer who doesn't like haskell or ML.
More OSS people need to understand this. My comment here wasn't about what I wanted. When I used NixOS everything was just fine. I had no problems with it from the standpoint you describe as a personal OS. But I was still able to identifiy the problem with NixOS as a consumer product or even as a product used at a company for development. This isn't a trivial problem. It's a major impediment that hinders adoption.
> someone like you or me who's willing to learn a completely new programming language to use an operating system
No, it's the other way. I'm using NixOS because I want to understand Nix better. I want to understand Nix better so that I can help this crowd:
> Most people and developers don't want to be a "participant". They need something that gets the job done.
I met a guy last semester who wasted 4 months of his graduate program (structural proteomics) trying to puzzle out how to run some x-ray laser scattering analysis software that was written in FORTRAN and handed to him on a flash drive. He's the person I want to help. I want him to be able to install nix wherever and type `nix run github:foo/barlasers` and be happy that barlasers works as expected, no need to become a NixOS user.
> Your disagreement represents a niche and if the devs cater to your disagreement then they cater to a small niche.
They're catering to the people who are willing to help them create a useful packaging and configuration ecosystem. Just because they're not catering to the end users of those packages doesn't make them insufficiently empathetic.
The alternative is a really comfy package manager and a bunch of broken packages. That's much worse. I see NixOS as a factory floor, if you wanna get your hands dirty we'll happily show you around, but the "easy button" experience that we're building happens where people press that button, not where it's made.
No, it's the other way. I'm using NixOS because I want to understand Nix better. I want to understand Nix better so that I can help this crowd:
> Most people and developers don't want to be a "participant". They need something that gets the job done.
I met a guy last semester who wasted 4 months of his graduate program (structural proteomics) trying to puzzle out how to run some x-ray laser scattering analysis software that was written in FORTRAN and handed to him on a flash drive. He's the person I want to help. I want him to be able to install nix wherever and type `nix run github:foo/barlasers` and be happy that barlasers works as expected, no need to become a NixOS user.
> Your disagreement represents a niche and if the devs cater to your disagreement then they cater to a small niche.
They're catering to the people who are willing to help them create a useful packaging and configuration ecosystem. Just because they're not catering to the end users of those packages doesn't make them insufficiently empathetic.
The alternative is a really comfy package manager and a bunch of broken packages. That's much worse. I see NixOS as a factory floor, if you wanna get your hands dirty we'll happily show you around, but the "easy button" experience that we're building happens where people press that button, not where it's made.
Learning nix to help the average user is a bit irrational as both are two opposing objectives.
Nix is for power users. Not for average users. It's pretty much the entire design philosophy.
Nix is for power users. Not for average users. It's pretty much the entire design philosophy.
I recently took a computational biology class which was way above my level. There I worked alongside scientists who have some pretty daunting software configuration problems. Their first approach is to just try every package manager that has the tool until they find one that works, and then they tell their peers to use that one.
I'm not proposing to teach them to write nix, but they can add it to the list of things they try, like:
$ conda install sra-tools ; sra-tools fastq-dump # error: tls version mismatch
$ nix build github:MatrixManAtYrService/sra-tools ; ./result/bin/fastq-dump # works
I was able to get them unstuck several times by just packaging something myself and pointing them at my repo. That's what I mean by help. Nix packages don't bit rot the way that others do. Packaging things with nix would be a great way to make sure we don't lose access to software that was written in the 80's.
I'm not proposing to teach them to write nix, but they can add it to the list of things they try, like:
$ conda install sra-tools ; sra-tools fastq-dump # error: tls version mismatch
$ nix build github:MatrixManAtYrService/sra-tools ; ./result/bin/fastq-dump # works
I was able to get them unstuck several times by just packaging something myself and pointing them at my repo. That's what I mean by help. Nix packages don't bit rot the way that others do. Packaging things with nix would be a great way to make sure we don't lose access to software that was written in the 80's.
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.
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.
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?
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
absent: everyone who understand the finer details on software packaging and already implemented different trade-offs than nix
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 `//`)
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.
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.
This is how I think of Dhall as well, which I highly recommend.
https://dhall-lang.org/
https://dhall-lang.org/
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
I think it is intuitive once you spend the time to read the docs. I think folks expect they can pick it up and hack at it like many other languages. It's one that is worth spending the time to work through the pills, understand what it is doing, why and how. A lot of the confusion and frustration I've seen people have with nix the language could have been avoided if they spent a little time to pick up at least the fundamentals.
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?
> The syntax is intuitive
Let me guess: you come from a ML or Haskell background?
> 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.
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.
> 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.
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.
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.
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!"
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!"
It's no more difficult than packer. The challenge is architectural, because a lot of times (and I am guilty of this as a developer myself) the infra architecture comes later or after the fact.
A lot of what makes declarative stuff nice is it comes with an implicit opinionated standard way of doing stuff. Nix tries to be way more general to the point of a whole programming language.
Compare that with Snap packages: https://snapcraft.io/docs/python-apps
Where everything is closer to true configuration not declarative programming. Apt and PyPi packages in, snap package out, install it like it was an exe or put it in an app store, give it some permissions, done.
They don't introduce any new concepts and there are few intermediate extra steps, it's all more of less pretty common ideas found in any tech workflow.
Compare that with Snap packages: https://snapcraft.io/docs/python-apps
Where everything is closer to true configuration not declarative programming. Apt and PyPi packages in, snap package out, install it like it was an exe or put it in an app store, give it some permissions, done.
They don't introduce any new concepts and there are few intermediate extra steps, it's all more of less pretty common ideas found in any tech workflow.
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.
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).
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).
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.
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.
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.
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.
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.
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?
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?
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).
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).
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/203ecda835bcf69633df71...
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/203ecda835bcf69633df71...
You make a good point! I don't know exactly how the internals of debian's package management work but I do know that it downloads packages from mirrors, probably unpacks the archive, verifies gpg signatures, parses metadata and starts resolving deps, extractice archives, launching scripts/triggers. Maybe if I have a better understanding of Nix internals like you it won't feel like a black box.
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.
There's some prospect of 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.
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.
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
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.
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?
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.
- 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.
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.
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.
A big problem (With everything, not just Mix) is nested config files.
Documentation says "Use this snippet" or "Add this to your configuration", but doesn't say where to add it.
Sometimes you have to paste the snipped three levels of nesting deep, and the docs assume you already know the language and cns figure it out yourself.
Meaning you can't use it without investing the time to learn it. But I don't wanna put too much time into it if nobody else is using it and it's not gonna be a common boring standard corporate choice that Just Works, because I'm not really a tinkerer distro person.
I think Python has it right with Flat is Better Than Nested. If you need nested anything, I'd rather things be redesigned to be more high level.
Failing that... more complete config examples, not just snippets, would be nice.
Documentation says "Use this snippet" or "Add this to your configuration", but doesn't say where to add it.
Sometimes you have to paste the snipped three levels of nesting deep, and the docs assume you already know the language and cns figure it out yourself.
Meaning you can't use it without investing the time to learn it. But I don't wanna put too much time into it if nobody else is using it and it's not gonna be a common boring standard corporate choice that Just Works, because I'm not really a tinkerer distro person.
I think Python has it right with Flat is Better Than Nested. If you need nested anything, I'd rather things be redesigned to be more high level.
Failing that... more complete config examples, not just snippets, would be nice.
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.
What dazzling things is docker facilitating? kinda just thought it was marginally decreasing sys-admin/op-management costs.
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
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
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
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.
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.
I find Nix to be very usable. People expect to be able to learn things without trying nowadays.
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
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
<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.
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.
> 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.
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.
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.