5 ms·
I've had the displeasure of being forced to use nix and to me it seems like an overengineered piece of garbage. I don't see why anyone should use this vs compet
by r32a_ 8y ago
I've had the displeasure of being forced to use nix and to me it seems like an overengineered piece of garbage. I don't see why anyone should use this vs competitors
- kjeetgill 8y agoHuh. I think this is the first bad experience with NIX I've ever heard on HN. Having only ever heard about it in passing but never worked with it myself I'm curious, what were you building when you'd encountered it and what issues did you have. Was there a particular language you'd preferred to have worked in?
- josteink 8y ago> Huh. I think this is the first bad experience with NIX I've ever heard on HN. Strictly speaking "Nix" may refer to two things, and I'm not sure which thing either of you are referring to, nor if you two are referring to the same thing. Personally I found the nix package-manager a bit odd, but to me that was not a deal-breaker for trying out NixOS. The bigeset problem for me was lacking packages... I was however willing to help the community out by trying to package the things I needed which wasn't already provided for. But then I had to use the Nix language. And that was a great displeasure, and I ended giving up NixOS all together because of this one pain point. And to address your comment: I think I've seen similar comments on HN at regular intervals. It's definitely not a one-off comment. If they had used another more standard language (like LISP!) I would probably still be on NixOS as my main OS. In the long run, I really hope Guix manages to get something good going. My biggest concern for Guix is that they will restrict the available packages by being overly zealous about package-licensing (like everything the FSF does).
- danieldk 8y agoBut then I had to use the Nix language. And that was a great displeasure, and I ended giving up NixOS all together because of this one pain point. Could you articulate why? I have only been using Nix for ~3 months, but so far I do not really have qualms with the Nix language. Maybe it is because I have written a fair bit of Haskell before. (Of course, I understand the argument that it would have been more comfortable if an existing language like Scheme was used.) My biggest concern for Guix is that they will restrict the available packages by being overly zealous a bout package-licensing (like everything the FSF does). Same here. When I got interested in NixOS/GuixSD I seriously considered using GuixSD, because Scheme is more familiar. But there are just some proprietary packages that I need for work (Skype) and at home. I didn't really feel like having to rely on third-party repositories, etc.
- josteink 8y ago> Could you articulate why? I have only been using Nix for ~3 months, but so far I do not really have qualms with the Nix language. I mean... It's not a "real" language in the sense that there exists any tooling, debuggers, unit-test suites or anything. You write your recipes and try to see if they work. And when they don't you have no idea why. With a real programming language (like Scheme) I could evaluate something working, compare it to my non-working stuff and probably figure out where it all went wrong. Chances are I could probably expand the macros and debug my way to a solution right within Emacs without ever launching a single external tool. There's just this huge gap between what you get and what you expect. And with Nix being a one-tricky pony, there's almost zero incentives for the community at large to try bridge that gap.
- deleted 8y ago[deleted]
- binaryphile 8y agoI found the nix-repl to be very helpful in this situation...you can also invoke command-line expressions directly with nix but it's a bit more arcane.
- rekado 8y ago> In the long run, I really hope Guix manages to get something good going. My biggest concern for Guix is that they will restrict the available packages by being overly zealous about package-licensing (like everything the FSF does). Guix co-maintainer here. The Guix project is not run by the FSF; it is part of the GNU project, because we subscribe to the idea of giving users the tools to take control of their computing. Packages available through the official Guix channel must be compliant with the Free System Distribution Guidelines: https://www.gnu.org/distros/free-system-distribution-guidelines.html The large package collection that comes with Guix is trivially extended through channels: a git repository containing Guix modules defining extra packages. You can do without git and just add a local directory of modules to GUIX_PACKAGE_PATH. At the institute where I work we're using channels to provide packages that are not available in Guix proper. It's very simple.
- profsnuggles 8y agoI recently posted on HN complaining about Nix and Guix. For myself (and I suspect many people) when installing GuixSD, before I even have the system running, I'm going to need to figure out how to package the Linux kernel with firmware for my wifi. Otherwise my ~$3k laptop is basically a brick. That is a big ask right up front. Glancing at the mailing list it seems like discussing non-free software is discouraged. Even if there is some well maintained Linux package on Github it would be difficult to find and evaluate before having any experience with Guix. It is your project and you can obviously have whatever rules you want. It just seems that Guix and Nix made some odd choices that are going to keep both projects in a very small niche.
- Ericson2314 8y agoOverengineered, hah. Most UX issues could be chalked up to it not doing enough!
- r32a_ 8y agoExactly, let's make the package manager do 100000 things.
- ilovecaching 8y agoHow were you forced to use Nix? I didn't know anyone was using Nix in a professional environment.
- laurentoget 8y agoI for one did use it professionally for years.
- r32a_ 8y agoCardano the cryptocurrency is written in Haskell and uses nix as it's package manager
- zingplex 8y agoPlease elaborate.
- pfranz 8y agoWould you mind elaborating? Who would you say are the competitors? I completely agree it's a waste to over complicate things if you never leverage it, but Nix seems like the perfect solution to a problem I can't imagine I'm the only one to have. Being able to build against different versions of glibc and a whole stack of dependencies out of the box is kind of amazing after dealing with dependencies. Flipping between version stacks by flipping a symlink is insane.
- GlennS 8y agoWhy would anyone use it versus its competitors? Here's why: 1. You can uninstall a thing and it will no longer affect your computer. 2. Your environment will work the same way on your colleague's computer. 3. Your environment will work the same way years down the line. 4. Your environment will probably work the same way years down the line, even after you've applied security updates. If it doesn't, it will probably be clear what's broken/different. 5. You can install many different environments on the same machine, and they will probably all work. On the rare occasions where they don't, it will be because they interact with system services or limited system resources, and it will be clearly defined how that happens. 6. All this is true across most programming languages, system services, and all sorts of tools. 7. You can combine this with direnv (or direnv-mode for Emacs) to make it so that you can just cd into a directory and magically get all the dependencies. 8. You can put the recipe for your environment in Git. Other than Nix and Guix, I don't know of any tool where these things are true. Docker and Virtual Machines get sort of half way, but tend to rot over time. But yes, it's difficult to learn and in many cases the usability is poor. Final bonus point: 9. Nix is so good that it can even make Autotools work correctly.
- deleted 8y ago[deleted]
- r32a_ 8y agoI don't care about those features, I just wanted to download the packages and it's dependencies and in the end it never did that. Nix is probably good for many things, but it's not simple and to me it's trying to do too many things.