Hacker News Reader

Comment by kertoip_1 | Hacker News Reader

The fact that such articles appear shows an untold problem of NixOS which is: complexity.

I've been a programmer and Linux user for many years, I know a lot of terminology behind it and I think it's a lot less of a problem for me to read technical documentation than for the average user. When I heard about NixOS I thought: "how awesome, it solves some of the problems that I have". But then I started to read official docs and dig into all of it and got quickly discouraged. It might solve "some of my problems" but at a time cost that I just couldn't afford. Well, maybe it's just not for me...

View on HN

Analogously, compare Emacs with VSCode.

It's much easier for someone to be productive with VSCode without having to go out of their way to learn much.

Whereas, Emacs' requires much more effort to learn, even just to get started; but is much more extensible than VSCode is.

For the user who doesn't want to spend much time learning, surely VSCode is better. For the user who wants to get the most out of their editor, Emacs is a reasonable choice.

I think Nix is comparable. Much of the time, Nix is quite straightforward to use. But, when you do run into something that's hard, Nix can be very difficult to work with.

Maybe there'll be a tool that's to Nix/NixOS what VSCode is to Emacs; where you get the benefits of a declarative config.

How is emacs more extensible than vscode when vscode is an electron app in which you're free to do anything a webpage might? I struggle to think of any thing emacs or its plugins can do that vscode extensions can't, and I'd be willing to bet that the extensions are already available and not "you could do it with dev time"

I think parent poster refers to emacs being essentially a lisp interpreter, plus lisp itself being a literal AST spit out, enabling all kinds of extensibility

e.g. Elisp supports advising functions; so you can hook functions to act around other functions which get executed. https://www.gnu.org/software/emacs/manual/html_node/elisp/Ad... -- AFAIU, VSCode doesn't allow for anything that powerful.

With VSCode, you've got your settings, and you've got the extensions you can install. With Emacs, the line between "plugin" and "configuration" is more blurred; you can write your own commands to cover how you do your work. -- It's more likely that an Emacs user has touched ELisp, than that a VSCode user has extended VSCode.

I recall running into a problem with VSCode extensions where you couldn't ensure one plugin would be loaded before another plugin. (e.g. loading the direnv plugin, before loading some other program which uses the loaded environment).

I thought the same thing for a long time. The reality is that I knew nothing about NixOS other than the sales pitch the day I installed it: nothing about the language, nothing about flakes or derivations or whatever. By the afternoon I had most of my setup replicated. By the next day I had both desktop and laptop running identical configurations.

I’ll echo this sentiment. While it may take a while to figure out how to do something initially, the great thing about NixOS is that you only have to figure out how to do it exactly once. As far as my main desktop OS, I figured out a config that I liked several years ago, and haven’t really tweaked much since then. I ran the rolling release for a while, but I’ve moved back to the stable release, which is… well, stable.

When I got my MacBook I thought "hey it would be neat to install gcc and friends using Nix". I struggled through outdated documentation to add packages, mixed up editing the files and `nix-env --install`, struggled with the `nix search` command requiring flakes or something, and never did figure out how to even update my package versions. Earlier I also tried installing NixOS and never actually got any use out of the disk at all.

As a programmer, nix (the package manager) has been saving grace for me. I use it in almost every project now and even in work to setup dev environments, ci builds, cross compiling and what not.

Complexity has both an essential and an accidental part. Nix is not (yet) as friendly as it could on the second part, but simply due to the problem domain it will have quite a bit of essential complexity, no matter what.

Package management is a complex problem and nix is the fist software that actually solves it, instead of just hiding it in the closet (e.g. docker-like solutions). If you want to deal with packages correctly (and I think we all want to), then this is the price.

Although it will improve on the accidental complexity part, e.g. currently many language ecosystems/software is not built with nix in mind.

Reply on news.ycombinator.com