10 ms·

Based on other comments like this, I gave it a try. Be prepared to sink dozens and dozens of hours learning the language, it’s features, and switching everythi

by qudat 5y ago

Based on other comments like this, I gave it a try. Be prepared to sink dozens and dozens of hours learning the language, it’s features, and switching everything over. Be prepared to get stuck when you are required to use an old version of a language and things don’t install correctly — and sometimes blocked by nix itself from installing it. Be prepared to get stuck if you are not in the happy path. Be prepared to get lost in the sometimes scant documentation. I love the idea of nix, but it did not work for me except for the simplest cases.

samhh 5y ago
I agree that the documentation story could be better. I also think it's a great shame that the language isn't statically-typed, so to understand how to use something I have to inspect its source code. I've found it to be quite flexible though. For example, here's a commit in which I apply a patch to a tool to solve a problem that the derivation hadn't taken into account (and absent a home-manager solution): https://github.com/samhh/dotfiles/commit/867dd3b4d4b3942a0aae91699a0e62bc6e1d5194 https://github.com/samhh/dotfiles/commit/867dd3b4d4b3942a0aa...
- omaranto 5y ago
  > I also think it's a great shame that the language isn't statically-typed, so to understand how to use something I have to inspect its source code. I understand everything in that sentence except the word "so".
  - samhh 5y ago
    Static types are documentative, and language servers often also show you things like JSDoc alongside the type signature. Nix has neither of these, hence I have to check the source code or run a build and see what happens. I really like Nix but in this particular way it feels like taking a big step backwards from the other languages I frequently use, particularly for a language in which you'll necessarily be constantly interacting with bespoke interfaces.
    - omaranto 5y ago
      Informative function signatures, allowing programmers to add per-function documentation, and tooling that displays those things are by no means limited to staticly typed languages. I guess knowing allowed types for each parameter is informative (more if very specific types are used rather than string or integer), but documentation usually specifies that anyway. And even knowing all the types isn't usually enough without documentation. My point is just that I've used plenty of libraries in dynamically typed languages without needing to read the source. And conversely, I've occasionally needed to look at the source of a function in a staticly typed language, to answer some question not answered by the types and documentation.
      - SkyMarshal 5y ago
        Being able to see a function's entire type signature at a glance is the single most useful way of documenting code I've ever come across. No alt-tabbing to docs or relying on an IDE to pop up hints, etc., it's just right there. Haskell is the ideal here, since it separates the type signature into its own separate line at the top of the function declaration. That confers readability and reduces cognitive overhead more than any other language I've used. It also changes the programming thought process. You can pseudo-code an entire program just with function type definitions. Then test that the type defs compile without error, and go back and implement the function definitions. As long as the function definitions adhere to their type signature, the program almost always works (barring some I/O errors). Not all statically typed languages are created equal. The ones fundamentally oriented around function type signatures, rather than variable types, are the ones I think parent had in mind in his comment.
shantnutiwari 5y ago
The Nix crowd is becoming a lot like the Rust crowd-- they hijack every conversation with "Have you tried Nix"? Like you, I find Nix hard to use and the docs confusing (beyond trivial examples). The amount of time the Nix mafia spends proselyting could be better spent making better docs
- tannhaeuser 5y ago
  I agree. I've got nothing against nix, but it frankly sucks that the top comment isn't about asdf which I had hoped to learn about. There should be special "-1 offtopic" comment flagging because it's a frequent phenomenon.
  - SkyMarshal 5y ago
    As a fan of Nix and NixOS, I agree with this assessment. Too often people hijack threads about a topic to discuss something related but totally different and off-topic. It's kind of annoying, even when I'm a fan of the off-topic thing. I've never heard of asdf and popped in here to read about it, people's experiences with it, etc. If I want to read about Nix/OS I'll find a thread on that, or go to /r/nixos, etc.
    - ravi-delia 5y ago
      I mean, just minimize the comment? I like seeing discussion on many related aspects of an article, it's cool seeing how things compare.
    - leaflets2 5y ago
      > Too often people hijack threads about a topic to discuss something related but totally different and off-topic And what are you doing :-)
      - SkyMarshal 5y ago
        Hijacking the hijacking of the thread ;p
soraminazuki 5y ago
I have the exact opposite experience. Nix is the best solution out there especially in the sort of situations that you describe. Nix provides a level of flexibility that other solutions simply do not offer. If a package in Nix doesn't fit your requirements for whatever reasons, you can create a modified version of a package with ease. For example, say that you need a version of Nginx built against a custom version of OpenSSL. You can do just that with a few lines of code: let mypatch = pkgs.fetchpatch { url = "https://example.com/bugfix-for-openssl.patch"; sha256 = "..."; }; openssl = pkgs.openssl.overrideAttrs (old: { # add build flags configureFlags = old.configureFlags ++ [ "--enable-foo" ]; # add dependencies buildInputs = old.buildInputs ++ [ pkgs.foo ]; # add patches patches = old.patches ++ [ mypatch ]; }); in nginx.override { inherit openssl; } Nix will even know which packages it'd need to build locally instead of downloading a prebuilt binary. You can't do that with other common package managers. You're stuck with whatever the package manager provides you. So if you're not in the happy path, you're out of luck. You'd either have to give up or build from scratch. If you need a bugfix for a particular package, you'd have wait until the fix reaches the package repository. When I was using Ubuntu, that was often until the next major release. None of this stuff is a problem with Nix, which allows for customization with very little effort. It's easy to learn about Nix if you know where to look for. Nix Pills [1] would be a good start. The core language is the easiest part. It's JSON, but with functions and variables for proper abstraction. The documentation, while imperfect, is quite extensive compared to a majority of other high profile open source projects. If the documentation fails you, the Nixpkgs repository [2] is an even more rich source of information. The code is well organized, and I was able to get familiar with writing Nix packages fairly quickly by grepping the codebase. And finally, Nix has a sizable community so you could always ask if you're stuck. [1]: https://nixos.org/guides/nix-pills/ https://nixos.org/guides/nix-pills/ [2]: https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs
- xrd 5y ago
  This is the best comment I've read on nix yet! I've been using nix as my daily OS for six months and I'm able to be productive. At the same time, I'm often confused as to whether I should use nix-shell, nix-env or modify my configuration files. Thanks for the great comment.
flurie 5y ago
I think an easy trap with nix is the immediate desire to have it manage everything, which usually involves installing NixOS. It's the equivalent of being airdropped into the Romanian countryside with working knowledge of French. I am trying to adapt nix for use with some teams I'm consulting on, and my goal is to make its usage as dead simple as possible for really high value tasks. I also feel like nix is immediately tangible and beneficial in a way that makes us want to get to the power user level, but I don't feel like wanting to learn, say, kubernetes means one automatically wants to learn to be a cluster operator. The scope and complexity are great, and I have experienced all of the things you have described as well. Now that I am fairly confident in my abilities, I think it's important to make sure we find ways to help everyone get the most out of it, even if it doesn't involve scaling the wall that is the learning curve.
- xpe 5y ago
  > I think an easy trap with nix is the immediate desire to have it manage everything, which usually involves installing NixOS. Can you clarity what you mean? What do you mean by "trap"? Which (if any) of the following concepts factor into your understanding? Broken expectations? Premature optimization? Over-engineering? Lock-in? Are you suggesting that many users of the Nix package manager "fall into a trap" and begin using NixOS? What do surveys and/or data show about usage of just the Nix package manager? Combined with NixOS?
  - flurie 5y ago
    Absolutely, and if it was not clear from the context, I call it a trap because that feels like what I'd fallen into at some point. Let me see if I can describe it better. The Nix ecosystem is attractive to me at a high level because it looks like it has the possibility to revolutionize a lot of the problems that come up with an increased focus on devops culture. The problem with the Nix ecosystem itself is that it is larger and more varied than it might appear. There are really three large entities in the ecosystem: nix the language, nix the package manager (nixpkgs), and nix the OS (NixOS). Despite the fact that there is a lot of overlap in some of the details of these three things, they are easily understood as separate entities. There are a bunch of smaller secondary entities such as nix-darwin, home-manager, devshell, and digga (formerly devos). The aim of these entities is usually to supplement, enhance, replace, or reproduce features of nixpkgs and/or NixOS. Each of these entities has its own learning curve. It takes surprisingly little nix knowledge to use it as a dev environment generator, but nixpkgs knowledge will help a bit more. Even within nixpkgs itself, each major language has a large ecosystem built up around facilitating package building and deployment, and these are extremely heterogeneous. Some of them require that you regenerate the entire matrix of package dependencies for the package manager (javascript, haskell). Some of them have tooling that allow you to get started with almost no effort (mach-nix for python). These all have their own peculiarities. NixOS has a ton of modules, all rather heterogeneous, on top of requiring more careful knowledge of how to put together a system than most other distros. And nix the language without nixpkgs is very small, and some of what it does have built in is necessary so it can bootstrap an actual stdlib from nixpkgs. The trap is sprung once you've been sold on the idea, and even seen it shine through some things, but feel like you have an entire wall to climb to get to a point of general competency. All of these things I've described, and even some of their subgroups, require new knowledge for a more complete understanding. I do not understand the details of many of the things I have described, and I would consider myself a power user at this point. What looks like one gigantic, insurmountable cliff is really dozens of much smaller cliffs, many of which are not necessary, at least not to most people. At one point I wanted to test my skills in a really generic way, so I helped fix broken packages on macOS during one of the two yearly regression periods where the community tries to get the CI builds passing. I picked the packages completely at random. Most of what I ended up fixing was C/C++ based, and I don't normally work in it, or I haven't for many years, but I feel like I learned a good bit about cmake. I don't really write Haskell, but I was able to fix a bug in a solving library having to do with a missing portability shim. I didn't have help for any of this, and in some cases I was either too stuck to fix the build or unable to fix it due to problems beyond my control. All of this is to say that I think getting to this point is a lot less painful if one takes a use case, preferably a narrow one, and focuses on learning whatever is necessary in the service of that use case. Some good topics are dev environments, using nix as an app/project builder, using nix to build containers, using nix to manage remote machines (the difference between these and personal machines is that the scope of these machines tends to be much smaller). I think people try to take on too many of these things simultaneously and end up overwhelmed. That's not to say that NixOS isn't worth learning, but I think many people could realize most or all of the real-world benefit if they use nix on an OS they're comfortable with. Coming back to my comparison of being dropped in the Romanian countryside, if you want to learn Romanian, start there. If you want to experience the countryside, maybe a guided tour is the way to go. If you want to learn about the life of Ligeti, you might not even need to learn Romanian! But total immersion is difficult and draining, and a failed immersion experience doesn't mean Romania is a bad place. So it is with Nix.
cr__ 5y ago
What really stings is that I could have written this exact comment in 2015, when I did the same thing.
tmpz22 5y ago
Don’t threaten Linux users with a good time.
packetlost 5y ago
Not as bad as the guix crowd IMO. They're like the nix/Rust "just use XYZ" crowd but also combined with the GNU zealots so you get the perfect overlap of annoying software purists. Really, I like the idea and I actually like the fact that they use Guile (scheme) instead of a home-built DSL, but guix is a horrible, poorly documented, doesn't work even on the happy path mess.
- rekado 5y ago
  "poorly documented" is a new one for me. It's got one of the best manuals out there. A little short on examples maybe, but there's a separate cookbook with tutorials, and lots of blog posts. But maybe I'm just a "GNU zealot".
  - packetlost 5y ago
    The documentation appears good, until you fall off the already very narrow happy-path to just get things working. I can't even get the hello-world program to work following the instructions exactly on a clean Ubuntu VM. I didn't mean to imply everyone who uses it is a GNU zealot, but there's definitely a subset who are.
- sph 5y ago
  I honestly never heard anyone on HN recommending Guix over Nix.
  - packetlost 5y ago
    I'm explicitly not recommending it. I want to like it, but it doesn't give me any reason to
- robertlagrant 5y ago
  Never heard of guix til now. An annoying piece of software with a cult-like following does sound up my street, though.
- b1n 5y ago
  New GUIX user here. I've found the documentation to be good and the "zealots" seem very friendly - maybe take another look.
tra3 5y ago
Do you think it's worth it to sink the hours up front for future efficiency gains?
- lelanthran 5y ago
  > Do you think it's worth it to sink the hours up front for future efficiency gains? "possible future efficiency gains".
  - xpe 5y ago
    Many things in the world are possible. I often find probable to be a more useful concept than possible. Any tool with deterministic results (such as Nix) are highly likely to reduce a whole class of future problems. With this in mind, the question shifts from rather vague talk about possible futures to various kinds of scenarios. What happens when software developers have a deterministic build system? On the whole, the benefits are significant. Sure, there are costs to get there. In my view, the benefits often outweigh the costs.
    - tra3 5y ago
      Thanks for your thoughts. I worded my question poorly, I suppose, but you got my meaning. I keep seeing nix mentioned alongside complaints about it's maturity but that seems par for the course for something new, doesn't it? Until a tool reaches critical mass sharp edges are to be expected. I'll look into nix again when I have an appropriate use case.
      - xpe 5y ago
        The Nix package manager on macOS isn't as smooth as Homebrew. Still, Nix is better in many ways. More broadly, even if it isn't as popular, Nix is a viable tool and also encourages us (developers) to seek out repeatability in our dependencies.
    - lelanthran 5y ago
      > Many things in the world are possible. I often find probable to be a more useful concept than possible. Any tool with deterministic results (such as Nix) are highly likely to reduce a whole class of future problems. I disagree with the whole "highly likely" bit. Just because something new has a large positive value, that does not mean that a large time-investment or effort-investment in it is likely to pay off. After all, it may never get traction to make the cost of learning it worthwhile - some other, newer, better, easier system could come along and be adopted instead. We've seen this play out again and again in the technology world[1]. In 2000, a large time and effort investment into UTF-16 would be wasted as the world adopted UTF-8 instead. A large time and effort invested into new languages with powerful features (Haskell, circa 2005) would be wasted as the industry largely ignored it in favour of (presumably) inferior alternatives. Is nix highly likely to provide solutions to a whole class of problems? Sure. Is it highly likely to be the dominant, or even a common tool, in the future that solves those problems? Doubtful; "easier-to-use" has always won against "can better solve problems". I see no evidence that this will change anytime soon. [1] I've found that by procrastinating about learning a new technology, I can sometimes manage to avoid having to learn it altogether, because the tech dies off before my procrastination does. By putting off learning VRML in 2001, it went away before I ever got to it. Likewise, I'll put off learning new things until I actually have a need for the solution they offer. At least then, even if they die out in a few years, I'd have at least solved my immediate problems.
knowmad 5y ago
As someone who has been using asdf daily for over a year now I can say from experience it's awesome and should absolutely replace all individual language managers as the standard way we manage language versions. I recently gave nix a try because of a hacker news comment and agree with most of the points in this comment. The fact that new users are encouraged to read not 1, but 3 separate manuals to grok the tool is extremely discouraging for new users. Also the fact that nix is currently transitioning to a new feature called flakes and deprecating channels signals to me that the ecosystem is not stable enough for me to recommend that my team at work use it right now. That being said, I intend to read at least 2 of the manuals and use nix for dependency management in my side projects and to manage my system dependencies. I think nix takes all the great things that asdf can do, to a whole new level. The dream of having a nix section in my projects 'Getting Started' that only has 2 steps (1. Install nix 2. Run `nix-shell`) is something I desperately want. I think nix is much like erlang in that it's incredibly powerful and solves a lot of common problems, but it's used and maintained by an old guard that went through the trouble of learning how to use it and maintains the "I did it, why can't you" mindset. The erlang ecosystem has been given new life and been made easily available to new users thanks to the awesome work done by Jose Valim and the rest of the elixir team and community. However, I really hope that it doesn't take 30 years and a new language built on top of nix for it to become accessible to everyone. For those working on nix and the new flake functionality please look to things like elixir and asdf for inspiration on documentation, ease of use and pragmatism. Help make the tool you love ubiquitous. It will ultimately make your life easier when working with new developers because they will already have nix installed. I intended to do everything I can to help push nix in this direction (once I understand how the hell it works) if anyone reading this, has some time on their hands and wants to improve the state of software development for everyone please go down the nix rabbit hole and try to find ways to contribute to making it more accessible.
randomblock1 5y ago
Same, nix seems like such a perfect solution- but it's prohibitively hard. Sure, I could use it and sink 12 hours into reading the documentation, or I could just install pyenv/nvm/etc and be done in 1 minute. Look at Python with Nix: https://nixos.wiki/wiki/Python https://nixos.wiki/wiki/Python And then consider the simplicity of `pyenv install x.x.x` and a requirements.txt.

by qudat 5y ago

samhh 5y ago

I agree that the documentation story could be better. I also think it's a great shame that the language isn't statically-typed, so to understand how to use something I have to inspect its source code. I've found it to be quite flexible though. For example, here's a commit in which I apply a patch to a tool to solve a problem that the derivation hadn't taken into account (and absent a home-manager solution): https://github.com/samhh/dotfiles/commit/867dd3b4d4b3942a0aae91699a0e62bc6e1d5194 https://github.com/samhh/dotfiles/commit/867dd3b4d4b3942a0aa...

omaranto 5y ago
> I also think it's a great shame that the language isn't statically-typed, so to understand how to use something I have to inspect its source code. I understand everything in that sentence except the word "so".
- samhh 5y ago
  Static types are documentative, and language servers often also show you things like JSDoc alongside the type signature. Nix has neither of these, hence I have to check the source code or run a build and see what happens. I really like Nix but in this particular way it feels like taking a big step backwards from the other languages I frequently use, particularly for a language in which you'll necessarily be constantly interacting with bespoke interfaces.
  - omaranto 5y ago
    Informative function signatures, allowing programmers to add per-function documentation, and tooling that displays those things are by no means limited to staticly typed languages. I guess knowing allowed types for each parameter is informative (more if very specific types are used rather than string or integer), but documentation usually specifies that anyway. And even knowing all the types isn't usually enough without documentation. My point is just that I've used plenty of libraries in dynamically typed languages without needing to read the source. And conversely, I've occasionally needed to look at the source of a function in a staticly typed language, to answer some question not answered by the types and documentation.
    - SkyMarshal 5y ago
      Being able to see a function's entire type signature at a glance is the single most useful way of documenting code I've ever come across. No alt-tabbing to docs or relying on an IDE to pop up hints, etc., it's just right there. Haskell is the ideal here, since it separates the type signature into its own separate line at the top of the function declaration. That confers readability and reduces cognitive overhead more than any other language I've used. It also changes the programming thought process. You can pseudo-code an entire program just with function type definitions. Then test that the type defs compile without error, and go back and implement the function definitions. As long as the function definitions adhere to their type signature, the program almost always works (barring some I/O errors). Not all statically typed languages are created equal. The ones fundamentally oriented around function type signatures, rather than variable types, are the ones I think parent had in mind in his comment.

shantnutiwari 5y ago

The Nix crowd is becoming a lot like the Rust crowd-- they hijack every conversation with "Have you tried Nix"? Like you, I find Nix hard to use and the docs confusing (beyond trivial examples). The amount of time the Nix mafia spends proselyting could be better spent making better docs

tannhaeuser 5y ago
I agree. I've got nothing against nix, but it frankly sucks that the top comment isn't about asdf which I had hoped to learn about. There should be special "-1 offtopic" comment flagging because it's a frequent phenomenon.
- SkyMarshal 5y ago
  As a fan of Nix and NixOS, I agree with this assessment. Too often people hijack threads about a topic to discuss something related but totally different and off-topic. It's kind of annoying, even when I'm a fan of the off-topic thing. I've never heard of asdf and popped in here to read about it, people's experiences with it, etc. If I want to read about Nix/OS I'll find a thread on that, or go to /r/nixos, etc.
  - ravi-delia 5y ago
    I mean, just minimize the comment? I like seeing discussion on many related aspects of an article, it's cool seeing how things compare.
  - leaflets2 5y ago
    > Too often people hijack threads about a topic to discuss something related but totally different and off-topic And what are you doing :-)
    - SkyMarshal 5y ago
      Hijacking the hijacking of the thread ;p

soraminazuki 5y ago

I have the exact opposite experience. Nix is the best solution out there especially in the sort of situations that you describe. Nix provides a level of flexibility that other solutions simply do not offer. If a package in Nix doesn't fit your requirements for whatever reasons, you can create a modified version of a package with ease. For example, say that you need a version of Nginx built against a custom version of OpenSSL. You can do just that with a few lines of code: let mypatch = pkgs.fetchpatch { url = "https://example.com/bugfix-for-openssl.patch"; sha256 = "..."; }; openssl = pkgs.openssl.overrideAttrs (old: { # add build flags configureFlags = old.configureFlags ++ [ "--enable-foo" ]; # add dependencies buildInputs = old.buildInputs ++ [ pkgs.foo ]; # add patches patches = old.patches ++ [ mypatch ]; }); in nginx.override { inherit openssl; } Nix will even know which packages it'd need to build locally instead of downloading a prebuilt binary. You can't do that with other common package managers. You're stuck with whatever the package manager provides you. So if you're not in the happy path, you're out of luck. You'd either have to give up or build from scratch. If you need a bugfix for a particular package, you'd have wait until the fix reaches the package repository. When I was using Ubuntu, that was often until the next major release. None of this stuff is a problem with Nix, which allows for customization with very little effort. It's easy to learn about Nix if you know where to look for. Nix Pills [1] would be a good start. The core language is the easiest part. It's JSON, but with functions and variables for proper abstraction. The documentation, while imperfect, is quite extensive compared to a majority of other high profile open source projects. If the documentation fails you, the Nixpkgs repository [2] is an even more rich source of information. The code is well organized, and I was able to get familiar with writing Nix packages fairly quickly by grepping the codebase. And finally, Nix has a sizable community so you could always ask if you're stuck. [1]: https://nixos.org/guides/nix-pills/ https://nixos.org/guides/nix-pills/ [2]: https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs

xrd 5y ago
This is the best comment I've read on nix yet! I've been using nix as my daily OS for six months and I'm able to be productive. At the same time, I'm often confused as to whether I should use nix-shell, nix-env or modify my configuration files. Thanks for the great comment.

flurie 5y ago

I think an easy trap with nix is the immediate desire to have it manage everything, which usually involves installing NixOS. It's the equivalent of being airdropped into the Romanian countryside with working knowledge of French. I am trying to adapt nix for use with some teams I'm consulting on, and my goal is to make its usage as dead simple as possible for really high value tasks. I also feel like nix is immediately tangible and beneficial in a way that makes us want to get to the power user level, but I don't feel like wanting to learn, say, kubernetes means one automatically wants to learn to be a cluster operator. The scope and complexity are great, and I have experienced all of the things you have described as well. Now that I am fairly confident in my abilities, I think it's important to make sure we find ways to help everyone get the most out of it, even if it doesn't involve scaling the wall that is the learning curve.

xpe 5y ago
> I think an easy trap with nix is the immediate desire to have it manage everything, which usually involves installing NixOS. Can you clarity what you mean? What do you mean by "trap"? Which (if any) of the following concepts factor into your understanding? Broken expectations? Premature optimization? Over-engineering? Lock-in? Are you suggesting that many users of the Nix package manager "fall into a trap" and begin using NixOS? What do surveys and/or data show about usage of just the Nix package manager? Combined with NixOS?
- flurie 5y ago
  Absolutely, and if it was not clear from the context, I call it a trap because that feels like what I'd fallen into at some point. Let me see if I can describe it better. The Nix ecosystem is attractive to me at a high level because it looks like it has the possibility to revolutionize a lot of the problems that come up with an increased focus on devops culture. The problem with the Nix ecosystem itself is that it is larger and more varied than it might appear. There are really three large entities in the ecosystem: nix the language, nix the package manager (nixpkgs), and nix the OS (NixOS). Despite the fact that there is a lot of overlap in some of the details of these three things, they are easily understood as separate entities. There are a bunch of smaller secondary entities such as nix-darwin, home-manager, devshell, and digga (formerly devos). The aim of these entities is usually to supplement, enhance, replace, or reproduce features of nixpkgs and/or NixOS. Each of these entities has its own learning curve. It takes surprisingly little nix knowledge to use it as a dev environment generator, but nixpkgs knowledge will help a bit more. Even within nixpkgs itself, each major language has a large ecosystem built up around facilitating package building and deployment, and these are extremely heterogeneous. Some of them require that you regenerate the entire matrix of package dependencies for the package manager (javascript, haskell). Some of them have tooling that allow you to get started with almost no effort (mach-nix for python). These all have their own peculiarities. NixOS has a ton of modules, all rather heterogeneous, on top of requiring more careful knowledge of how to put together a system than most other distros. And nix the language without nixpkgs is very small, and some of what it does have built in is necessary so it can bootstrap an actual stdlib from nixpkgs. The trap is sprung once you've been sold on the idea, and even seen it shine through some things, but feel like you have an entire wall to climb to get to a point of general competency. All of these things I've described, and even some of their subgroups, require new knowledge for a more complete understanding. I do not understand the details of many of the things I have described, and I would consider myself a power user at this point. What looks like one gigantic, insurmountable cliff is really dozens of much smaller cliffs, many of which are not necessary, at least not to most people. At one point I wanted to test my skills in a really generic way, so I helped fix broken packages on macOS during one of the two yearly regression periods where the community tries to get the CI builds passing. I picked the packages completely at random. Most of what I ended up fixing was C/C++ based, and I don't normally work in it, or I haven't for many years, but I feel like I learned a good bit about cmake. I don't really write Haskell, but I was able to fix a bug in a solving library having to do with a missing portability shim. I didn't have help for any of this, and in some cases I was either too stuck to fix the build or unable to fix it due to problems beyond my control. All of this is to say that I think getting to this point is a lot less painful if one takes a use case, preferably a narrow one, and focuses on learning whatever is necessary in the service of that use case. Some good topics are dev environments, using nix as an app/project builder, using nix to build containers, using nix to manage remote machines (the difference between these and personal machines is that the scope of these machines tends to be much smaller). I think people try to take on too many of these things simultaneously and end up overwhelmed. That's not to say that NixOS isn't worth learning, but I think many people could realize most or all of the real-world benefit if they use nix on an OS they're comfortable with. Coming back to my comparison of being dropped in the Romanian countryside, if you want to learn Romanian, start there. If you want to experience the countryside, maybe a guided tour is the way to go. If you want to learn about the life of Ligeti, you might not even need to learn Romanian! But total immersion is difficult and draining, and a failed immersion experience doesn't mean Romania is a bad place. So it is with Nix.

cr__ 5y ago

What really stings is that I could have written this exact comment in 2015, when I did the same thing.

tmpz22 5y ago

Don’t threaten Linux users with a good time.

packetlost 5y ago

Not as bad as the guix crowd IMO. They're like the nix/Rust "just use XYZ" crowd but also combined with the GNU zealots so you get the perfect overlap of annoying software purists. Really, I like the idea and I actually like the fact that they use Guile (scheme) instead of a home-built DSL, but guix is a horrible, poorly documented, doesn't work even on the happy path mess.

rekado 5y ago
"poorly documented" is a new one for me. It's got one of the best manuals out there. A little short on examples maybe, but there's a separate cookbook with tutorials, and lots of blog posts. But maybe I'm just a "GNU zealot".
- packetlost 5y ago
  The documentation appears good, until you fall off the already very narrow happy-path to just get things working. I can't even get the hello-world program to work following the instructions exactly on a clean Ubuntu VM. I didn't mean to imply everyone who uses it is a GNU zealot, but there's definitely a subset who are.
sph 5y ago
I honestly never heard anyone on HN recommending Guix over Nix.
- packetlost 5y ago
  I'm explicitly not recommending it. I want to like it, but it doesn't give me any reason to
robertlagrant 5y ago
Never heard of guix til now. An annoying piece of software with a cult-like following does sound up my street, though.
b1n 5y ago
New GUIX user here. I've found the documentation to be good and the "zealots" seem very friendly - maybe take another look.

tra3 5y ago

Do you think it's worth it to sink the hours up front for future efficiency gains?

lelanthran 5y ago
> Do you think it's worth it to sink the hours up front for future efficiency gains? "possible future efficiency gains".
- xpe 5y ago
  Many things in the world are possible. I often find probable to be a more useful concept than possible. Any tool with deterministic results (such as Nix) are highly likely to reduce a whole class of future problems. With this in mind, the question shifts from rather vague talk about possible futures to various kinds of scenarios. What happens when software developers have a deterministic build system? On the whole, the benefits are significant. Sure, there are costs to get there. In my view, the benefits often outweigh the costs.
  - tra3 5y ago
    Thanks for your thoughts. I worded my question poorly, I suppose, but you got my meaning. I keep seeing nix mentioned alongside complaints about it's maturity but that seems par for the course for something new, doesn't it? Until a tool reaches critical mass sharp edges are to be expected. I'll look into nix again when I have an appropriate use case.
    - xpe 5y ago
      The Nix package manager on macOS isn't as smooth as Homebrew. Still, Nix is better in many ways. More broadly, even if it isn't as popular, Nix is a viable tool and also encourages us (developers) to seek out repeatability in our dependencies.
  - lelanthran 5y ago
    > Many things in the world are possible. I often find probable to be a more useful concept than possible. Any tool with deterministic results (such as Nix) are highly likely to reduce a whole class of future problems. I disagree with the whole "highly likely" bit. Just because something new has a large positive value, that does not mean that a large time-investment or effort-investment in it is likely to pay off. After all, it may never get traction to make the cost of learning it worthwhile - some other, newer, better, easier system could come along and be adopted instead. We've seen this play out again and again in the technology world[1]. In 2000, a large time and effort investment into UTF-16 would be wasted as the world adopted UTF-8 instead. A large time and effort invested into new languages with powerful features (Haskell, circa 2005) would be wasted as the industry largely ignored it in favour of (presumably) inferior alternatives. Is nix highly likely to provide solutions to a whole class of problems? Sure. Is it highly likely to be the dominant, or even a common tool, in the future that solves those problems? Doubtful; "easier-to-use" has always won against "can better solve problems". I see no evidence that this will change anytime soon. [1] I've found that by procrastinating about learning a new technology, I can sometimes manage to avoid having to learn it altogether, because the tech dies off before my procrastination does. By putting off learning VRML in 2001, it went away before I ever got to it. Likewise, I'll put off learning new things until I actually have a need for the solution they offer. At least then, even if they die out in a few years, I'd have at least solved my immediate problems.

knowmad 5y ago

As someone who has been using asdf daily for over a year now I can say from experience it's awesome and should absolutely replace all individual language managers as the standard way we manage language versions. I recently gave nix a try because of a hacker news comment and agree with most of the points in this comment. The fact that new users are encouraged to read not 1, but 3 separate manuals to grok the tool is extremely discouraging for new users. Also the fact that nix is currently transitioning to a new feature called flakes and deprecating channels signals to me that the ecosystem is not stable enough for me to recommend that my team at work use it right now. That being said, I intend to read at least 2 of the manuals and use nix for dependency management in my side projects and to manage my system dependencies. I think nix takes all the great things that asdf can do, to a whole new level. The dream of having a nix section in my projects 'Getting Started' that only has 2 steps (1. Install nix 2. Run `nix-shell`) is something I desperately want. I think nix is much like erlang in that it's incredibly powerful and solves a lot of common problems, but it's used and maintained by an old guard that went through the trouble of learning how to use it and maintains the "I did it, why can't you" mindset. The erlang ecosystem has been given new life and been made easily available to new users thanks to the awesome work done by Jose Valim and the rest of the elixir team and community. However, I really hope that it doesn't take 30 years and a new language built on top of nix for it to become accessible to everyone. For those working on nix and the new flake functionality please look to things like elixir and asdf for inspiration on documentation, ease of use and pragmatism. Help make the tool you love ubiquitous. It will ultimately make your life easier when working with new developers because they will already have nix installed. I intended to do everything I can to help push nix in this direction (once I understand how the hell it works) if anyone reading this, has some time on their hands and wants to improve the state of software development for everyone please go down the nix rabbit hole and try to find ways to contribute to making it more accessible.

randomblock1 5y ago

Same, nix seems like such a perfect solution- but it's prohibitively hard. Sure, I could use it and sink 12 hours into reading the documentation, or I could just install pyenv/nvm/etc and be done in 1 minute. Look at Python with Nix: https://nixos.wiki/wiki/Python https://nixos.wiki/wiki/Python And then consider the simplicity of `pyenv install x.x.x` and a requirements.txt.