Hacker News Reader

Comment by shantnutiwari | Hacker News Reader

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

View on HN

Hum... Every time I see Nix cited somewhere, it's somebody who tried it and didn't manage to get expertise out of the documentation maze. (You can add me there too.)

But it's no wonder that people keep commenting that Nix is an awesome idea that solves a lot of problems. That's because it's an awesome idea that solves a lot of problems (yeah, like Rust).

It is also completely undiscoverable (not completely unlike Rust), and that's why almost nobody uses it. But that's a matter of improving the documentation or maybe fixing one or two superficial problems on the language.

> But that's a matter of improving the documentation or maybe fixing one or two superficial problems on the language.

Based on a quick check of their Wikipedia page, Nix has been around for 15 years, since 2007.

So those for sure look like structural problems. I don't know which ones exactly, but paraphrasing Tolstoi, popular software products are popular in much the same way, while unpopular ones are unpopular in their own unique ways.

In my experience almost no open source project that hasn't entered the mainstream in its first 10 years manages to turn the ship around, unless it lucks into a major change of environment. Programming languages are sometimes exempt if they have a "killer" library or framework pop up.

Nix just got a huge overhaul, with most functionality getting bundle under a single easy to use 'nix' command (i.e. similar to 'apt'), rendering a lot of the old commands obsolete. That currently creates a bit of a confusing situation, as lots of docu is about old commands, while new commands that look similar can behave quite a bit different (e.g. 'nix-shell' != 'nix shell'). Nix Flakes are another new thing and also create a bit of confusion and ugliness (e.g. packages being named 'nixpkgs#legacyPackages.x86_64-linux...').

That said, I haven't found Nix hard to use, quite the opposite. The new 'nix' command is pretty self explanatory, it's just a little incomplete in spots. And the Nix language is quite simple and easy to understand if you have ever touched a functional language. Compared to all the other Linux stuff I have played with over the years, it was a very pleasant experience so far.

Nix ain't trying to win marketshare it's trying to be amazing. But it takes guts to be amazing and that means a lot of people don't manage to use Nix.

HN tends to see success in terms of adoption rate & ranking. Nix is on another plane. It's beyond critical mass. And for people like me, it is a huge force multiplier. But I had to grind my way to the point where that is true.

I tend to not bother selling people on it. People who want what Nix does will find it at some point. So I just focus on using Nix myself in a world of worse tools. Feels great.

Oh, I'm not selling these cars. No, no. These babies sell themselves.

The difference between the person you're replying to and a car salesman is that they're a user and not a salesman.

Well, Nix is mainstream.

Evidence of that is that you can just talk about it by name here on HN without explaining what it is.

That could just as easily be attributed to the word Nix being easy to search for. But even if everyone on HN is aware of what it is, that doesn't make it mainstream by any definition I can think of. There are countless examples in the world of things that most people (in a given audience) are aware of, but that almost none of them participate in.

Is Haskell mainstream? What about committing murder?

It is horrible searching for Nix stuff because of all the *nix stuff.

And yes, this is 100% Nix's fault

Your claim is that software doesn't go from non-mainstream into popular if it stays non-mainstream for a decade. I'm really not willing to discuss the definition of "mainstream", but there are plenty of cases of software that stayed a decade as "everybody knows it, nobody uses it" and eventually got popular.

> Well, Nix is mainstream. Evidence of that is that you can just talk about it by name here on HN without explaining what it is.

I would say that HN is far from mainstream.

COBOL is mainstream?

Yeah, frustration on both sides here. On one hand, I can see how the nix evangelism can get annoying, especially here on HN. On the other hand the nix crowd is seeing a parade of ad hoc, informally-specified, niche implementations of way-less-than-half of nixpkgs. This is an important problem, maybe one of this most important problems the tech world is grappling with right now, and there is already a solution.

The reality is that the docs are fine. The reference material is comprehensive, and there are some very good tutorials and introductory essays to get people started. The problem is that it's difficult. Nix is very, very different from what people already know, and it takes quite a bit of effort to learn how it works. Most people just aren't prepared to do that much work just to install some software.

Nope nope nope. They're not fine. Nix is really really hard to use. I worked for a company that ran all the ops with Nix managed by some of the contributors. Every time I wanted to do something I'd have to get DevOps to do it for me. I've never ever had that level of difficulty doing stuff outside of a Nix environment and I really, really tried. Most of my colleagues who are fairly decent developers struggled with it too. It's the only tech I advise against when it's mentioned nowadays. And I want to like it.

On the other hand only Nix (to my knowledge) guarantees truly reproducible builds.

It helps that people who are into Nix most often use NixOS. NixOS is the only distro I've written packages for. It's not even particularly hard since there's a lot of inspiration to find in the official and community repos + people sharing personal configurations.

The UX wasn't the best but it's improving.

It remains extremely reliable which is not something that you could say of other systems.

I went all in and used NixOS too, but things like managing CI with Hydra, running perf tests on Nix ops clusters, debugging 10K+ Nix repos… you start to get it down and then things change like with flakes… and all the tools like Nix2Stack, Nix2Cabal, Nix2Docker, managing secrets, user profiles, none of it is existing knowledge you can bring or really take elsewhere. If you’re familiar with the ‘innovation token’ idea Nix would take all of them in my eyes for a project.

Docker is more pragmatic unless you spend hundreds of hours on Nix, in my opinion.

Sorry but the notion that the docs are fine is laughable. Most nix functions don't even have doc comments. You have to figure them out by delving into examples in the depths of github. Nix is in dire need of a culture of providing documentation comments, along with a tool that builds them into a website, like rustdoc or haddock.

If the problem is that it's difficult and the documentation is not making that difficulty simple enough to use, then the documents are not fine. Simple as.

If the problem is that it's difficult to learn to fly a fighter jet, and the documentation is not making it simple, the real problem is that the documentation is not fine. Simple as that.

As someone who has a recreational pilot license (sure, not jets, but still) you just reinforced the point of the previous comment rather than refute it for me.

Most pilot text books are absolutely horribly written, finding a good one takes significant effort. Reading just an ok book shines a light on how absolutely trash the majority of pilot text books are and that it is absolutely bad "documentation" that is partially to blame for it being difficult to learn.

I was trying to say, that some things are going to be hard for most people, because they're inherently a bit hard.

Just like inherent complexity in some software or business problems.

Maybe airplanes wasn't the best thing to compare with -- the comment below compares with C instead, maybe that's better. I never flew a plane.

When you frame it like that, the question then becomes "do you actually need the fighter jet?" and "why are all these people suggesting I use a fighter jet?"

That's pushing the analogy past where it breaks and missing the point. Take someone who has only ever written C-like code. Hand them a Scheme, maybe Racket. You expect them to initially have difficulty regardless of the quality of documentation. It's a different way of thinking about and doing things and there's a lot of it to deal with.

> The reality is that the docs are fine

then show me where `nix-env`'s `--arg` and `--argstr` is documented.

That's documented right in the man page.

  --arg name value
    This option is accepted by nix-env, nix-instantiate and nix-build. When 
    evaluating Nix expressions, the expression evaluator will automatically try to 
    call functions that it encounters. [...]

Also in the manual:

https://nixos.org/manual/nix/stable/command-ref/opt-common.h...

The ad-hoc solutions you're talking about are often highly usable, a virtue often forgotten by software evangelists. Nix's learning curve will keep away people who are disciplined in avoiding yak-shaving, as the language specific version enables productivity now. Maybe adding a layer on top of Nix, like create-react-app is to webpack, can make it a better option for immediate productivity oriented developers.

A positive of taking the nix brick road is if you get bored of software development you'll have enough yak fur to retire.

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.

> the top comment isn't about asdf which I had hoped to learn about

Oh I think you're using HN wrong. To learn about the subject you can read the actual article that's linked to. No guarantees about the comments section.

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.

I mean, just minimize the comment? I like seeing discussion on many related aspects of an article, it's cool seeing how things compare.

> Too often people hijack threads about a topic to discuss something related but totally different and off-topic

And what are you doing :-)

Hijacking the hijacking of the thread ;p

I feel like what you are critiquing is explicitly something HN encourages.

That’s funny because the documentation is fairly good. Short attention span?

Life is too short to spend hundreds or thousands of hours learning a tool to save you time. Nix might give you 'perfect' reproducible builds but does the time saved from this beat the time taken to learn it? I'm skeptical.

They do seem to share a fondness for executing curl output

This criticism is getting old. Piping curl output to bash is no less secure than installing a package via any other mechanism. Either you trust the source or you don't. I trust it more than I trust npm or pip because I'm typically getting it from the primary source instead of relying on a middleman that's got a poor track record.

It may be old, but it is valid, and it allows me to mock Rust and Nix advocates at the same time; who could resist?

If there's a SHA hash, served by a different server, an attacker would have to compromise both -- now just one?

"Someone else replaces the good program with a malicious program" is the attack vector people are worried about when talking about sha256.

But, since you're downloading & running code written by someone else, it seems weird to talk about that but ignore "what if this program I'm downloading does something malicious".

Presumably you trust the authors or you wouldn't be downloading it to begin with. The primary concern isn't "what if the authors are out to get me" it's "what if someone impersonates or compromises the authors".

Indeed, and this can be done semi-covertly given that one can detect a "curl install" server-side [1] and serve-up hostile code in just that case

[1] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Thanks! Interesting (the cURL stuff)

Reply on news.ycombinator.com