Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Curse of NixOS

blog.wesleyac.com

Post reply on HN
Print view View original

81–90 of 361 posts

Re: The Curse of NixOS

#81

Post by the_duke »

dangerbird2 wrote: post #47
gnu wrote: post #37

NixOS and Guix are nice! Guix folks are doing some wonderful work off late. I have used NixOS for a while. But for casual desktop GNU/Linux users, it seem like solving a problem that doesn't exist. Have been using Debian on all my computers since 1998. Unless you are using Debian unstable and updating it daily, I hardly hit any breakage. Servers and deployments is another story.

How does Guix compare to Nix? It seems like by using a scheme-based DSL instead of an ad-hoc configuration language, it solves one of the main complaints the author has about Nix.

Guix is cool but has two big drawbacks:

The major one: package ecosystem. Nix has the largest and most up to date package repo of any distro [1]).

Nix is already somewhat niche, but the Guix community is tiny.

They also have a hard stance against proprietary software, so many things that are packaged for Nix aren't for Guix.

Second: it's pretty slow. A lot of the Nix functionality is implemented in C++ . Guix is all written in Scheme, and uses a rather slow implementation.

The main advantage is more coherent tooling and documentation. (Guix is much younger and doesn't have decades of legacy cruft)

[1] https://repology.org/repositories/statistics

Re: The Curse of NixOS

#82

Post by avakand »

otabdeveloper4 wrote: post #15
rgoulter wrote: post #6

"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…

> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". It's too simple and straightforward. Writing Nix expressions is a bit like writing Javascript without frameworks or libraries. Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)

https://github.com/divnix/devos is something close to a framework.

I agree that language is too simple. Also I think some degree of IDE / language server support would help a lot. Refactoring modules, writing and importing custom functions was a bad experience for me - some arcane stacktraces were common, using repl was too verbose and with no clear way to debug whole configuration.

Re: The Curse of NixOS

#83

Post by light_hue_1 »

Nix has two kinds of problems: the language and the interface. They can solve interface problems, but the Nix language is a tumor that won't be easily removed.

The problem is that Nix the language is the worst of all worlds:

- You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are safe to inspect. This kills debugging.

- Everything in Nix is recursive, datastructures contain copies of themselves as hacks to avoid building proper APIs. So again, you can't print anything, even if you're sure that printing the object won't do something crazy to your store.

- There are almost no APIs and no uniformity in Nix. Packages are given total freedom to do anything. The Python ecosystem works totally differently from the Haskell one which works totally differently from the C++ one. It's insane. They use different datastructures, functions, etc. To do the same thing.

- The Nix language has impossible error messages. You will get stuck. You can't view values and you can't get error messages. There's no moving forward from that unless you ask someone.

- Laziness in Nix is different from laziness in Haskell. In Haskell, it's mostly about performance improvements and some cool tricks here and there. In Nix, laziness fundamentally means something: you build up packages and you force them to install them.

Nix the package manager also has serious issues:

- You cannot install Nix in your home account without root permissions (yes, there are hacks, but they break terribly). So Nix is actually less isolated and less portable than something like Anaconda!

- The commandline experience is terrible. Nothing makes any sense. Not the names of the tools. Not their arguments. Why sometimes something is a binary and other times it's a mode of another tool, etc.

- In exchange for making some hard things easy, Nix makes a lot of easy things very hard. Sure, it will manage an isolated environment. But, now you want a package from pip that isn't in Nix? There is literally no way for you to figure out how to do this, you need to find a tutorial online, hope it's up to date enough to work, and follow it step by step. And.. there's a good chance you misunderstood what the tutorial was doing and won't have the correct environment at the end.

Re: The Curse of NixOS

#84

Post by agumonkey »

valyagolev wrote: post #64
gypsyharlot wrote: post #2

I always found Guix more appealing, because it uses a programming language that is useful for other things as well (GNU Guile). I really can't stand having to learn a new language for each thing I want to manage.

as much respect as I have for Guile, I'd love the nix configuration language to have at least partially enforced types...

time for hix .. and lets revive http://lambda-the-ultimate.org/node/299

Re: The Curse of NixOS

#85

Post by light_hue_1 »

ryukafalz wrote: post #70
assbuttbuttass wrote: post #66

Earlier quoted context omitted.

As someone who's used Guix: They only package linux-libre, so if your device needs proprietary wifi, you're out of luck. Also they package icecat instead of firefox which is kind of cool. I tried to package slash'em a few years ago, and found it very difficult. The documentation is gigantic and it's hard to find what you're looking for. I found folks on IRC very helpful.

>They only package linux-libre, so if your device needs proprietary wifi, you're out of luck. I wouldn't say you're out of luck in that case. If you need upstream Linux, nonguix has it: https://gitlab.com/nonguix/nonguix

Oh yeah, nonguix. What a mess.

An unsupported pile of packages that break regularly. And if you dare ask a question about it in any official forum you're kicked out.

Nix has its issues, but guix is ideologically radical in a extremist "We don't care if your machine is unusable, enjoy your freedom", kind of way.

Re: The Curse of NixOS

#86

Post by virchau13 »

ashtonkem wrote: post #23

The real break for me using NixOS as a regular driver was that I just could not figure out how to get Ruby on Rails to play nice with it. NixOS breaks a lot of assumptions that programs make about $PATH, and even if it's done for good reasons it plays holy hell with the development stack of some languages. I eventually gave up and moved my dev setup back to OSX (and then that PC died anyways). Maybe they've fixed it…

It's worth noting that one can handle really badly behaving software using buildFHSUserEnv.

Re: The Curse of NixOS

#87

Post by kstenerud »

ghostwriter wrote: post #28
TheYumasi wrote: post #12

Earlier quoted context omitted.

> Maybe that is difficult for people who haven't had an experience with pure/functional programming? I found my understanding of the Nix language became a lot better once I started learning some Haskell. Specifically once I understood what currying was about. My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough.

> My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough. How hard have you tried? It's literally two clicks and one scroll away from the official home page: https://nixos.org/ -> click "Learn" -> Scroll down -> click "Full Nix Manual": https://nixos.org/manual/nix/stable/expressions/builtins.htm...

The other problem is the condescending replies from the higher tier nix folks while everyone else struggles. I almost think they garner a sadistic pleasure in watching everyone fail.

After months of "It's obviously this" and "you're not even trying" and "have you even looked?" and "there are plenty of examples out there already" and "you should start out by reading the introduction docs" and "you obviously don't know how functional languages work", I just stopped bothering.

Re: The Curse of NixOS

#88

Post by HotHotLava »

ghostwriter wrote: post #50
rgoulter wrote: post #35

Earlier quoted context omitted.

Nix is wonderful, but absolutely is under-documented. (In part due to a small community, etc.). A couple of examples I've run into: https://github.com/NixOS/nix/issues/2259 showed people trying to make use of the "hello world" package which was given in the NixPkgs manual, but couldn't quite figure out how to get it to build. e.g. if you want a package that's a simple script, "writeScriptBin" seems like what you'd wa…

> you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri ... Is it too much to ask from developers in 2022? At source, the function is well documented and is provided with an example [1]. The only missing part is a rendered HTML with the same information. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

It's one thing to look at the source, it's another thing to know that you have to look inside `pkgs/build-support/trivial-builders.nix` to find the documentation. One of the main advantages of reference documentation is a central place to look up what things do.

Re: The Curse of NixOS

#89

Post by avakand »

patrec wrote: post #79

I think the author is quite wrong that the nix language is not very good and hard to learn. In fact it's not only the best external DSL I've seen, but also one of the few cases where inventing a new language rather than just repurposing a subset of something already established looks like a good decision to me. In fact, I consider it a marvel of language design. The mix of properties that nix has (laziness, purity, r…

>That is not to say there are no significant problems with it: the lack of static typing coupled with low runtime performance and bad error messages and debugging support means tracking down more complicated errors can be a pain and the laziness can further compound this.

Some of this problems can be aleviated with good IDE support or language server.

Re: The Curse of NixOS

#90

Post by emptysongglass »

avakand wrote: post #82
otabdeveloper4 wrote: post #15

Earlier quoted context omitted.

> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". It's too simple and straightforward. Writing Nix expressions is a bit like writing Javascript without frameworks or libraries. Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)

https://github.com/divnix/devos is something close to a framework. I agree that language is too simple. Also I think some degree of IDE / language server support would help a lot. Refactoring modules, writing and importing custom functions was a bad experience for me - some arcane stacktraces were common, using repl was too verbose and with no clear way to debug whole configuration.

I just got a spare mini-PC up on DevOS over the weekend! It's currently looking for maintainers but it's cutting edge (think hlissner's NixOS config but more generic) and gives you a huge amount of flexibility out of the box. Highly recommended if you want a Flake-based NixOS system, local or remote but don't know where to start or you'd like an example of best practices to build off of.
Post reply on HN