Live data from Hacker News

I think it's time to give Nix a chance

maych.in

61–70 of 156 posts

Re: I think it's time to give Nix a chance

#61
post #45

Earlier quoted context omitted.

> some customer imposes it on our delivery contract It's happening: Companies are adopting Nix [0] and you may see such requirement come up some time. [0]: https://github.com/ad-si/nix-companies

In the bubble I live on, classical VMs have become the exception nowadays, containers and serverless deployments are the rule now. I am yet to see any classical VM deployment isn't one variation of Debian, Ubuntu, Red-Hat, SuSE. Note how that list has a certain startup feeling to the company list, not boring big corp.

Arista, D.E. Shaw, Google are boring big corp

Several of those companies (replit) are building their business on nix.

With nix, even containers are optional.

Re: I think it's time to give Nix a chance

#63
post #45

Earlier quoted context omitted.

> some customer imposes it on our delivery contract It's happening: Companies are adopting Nix [0] and you may see such requirement come up some time. [0]: https://github.com/ad-si/nix-companies

In the bubble I live on, classical VMs have become the exception nowadays, containers and serverless deployments are the rule now. I am yet to see any classical VM deployment isn't one variation of Debian, Ubuntu, Red-Hat, SuSE. Note how that list has a certain startup feeling to the company list, not boring big corp.

> In the bubble I live on, classical VMs have become the exception nowadays, containers and serverless deployments are the rule now.

Nix does not require NixOS, and I would even wager that in corporate dev environments it's most often used in a standalone manner.

You can install Nix on Debian/Ubuntu/RedHat, get a reproducible local dev environment and build reproducible OCI images that can be deployed to K8S/Cloud Run/Fargate/etc [0], without ever touching NixOS.

[0]: https://nix.dev/tutorials/nixos/building-and-running-docker-...

Re: I think it's time to give Nix a chance

#64

What is the supply chain security story with Nix packages? I stick mostly to reasonably popular Debian packages. My thinking is that if one of them has a serious vulnerability it will get fixed quickly or a lot of people have much bigger problems than me. I always worry about niche package systems, where it should be much easier to sneak in something malicious and it could linger there for a long time undetected.

As I see it there are three components of software supply chain security: - is this actually the binary that comes from that code? - is that code trustworthy? - is this binary trustworthy? Nix focuses on the first. If you can solve that problem, there's still nothing preventing bad guys from publishing malicious code, or from distributing malicious binaries which did not actually come from the code that they claim to…

Thanks for that detailed argument, especially for pointing out the three necessary components.

I agree even with the following paragraph in principle:

"If you're wondering whether whatever.sh is safe in the first place, and you want some council of elders to pinky promise that it's safe to run, then I don't think the nix ecosystem has much to offer you."

For me it is not so much about what the council of elders says, but more about when FAANG and Co. are OK to run a binary I think needn't worry about the rest. Or to think this further, they should care more about Nix than I should.

Re: I think it's time to give Nix a chance

#65
post #44

Earlier quoted context omitted.

> Welcome to the honeymoon phase. Mine lasted about a year Mine has been going on since 2016, what am I doing wrong?

> they just don't try hard enough The answer was in my post. Nix isn't for everyone, and that's OK.

I've returned and my new approach was to learn:

1. The repl for exploration 2. The language (read nix.dev) 3. Read the nixos manual

And with that it started to make sense.

Re: I think it's time to give Nix a chance

#66

Something I have always wondered about is how Nix interacts with my editor and language servers. I use emacs. The emacs LSP mode starts up a language server process for a language like Python or Go. If I use Nix to manage development dependencies like my compiler, linting tools, and even language-specific dependencies, then how do I get the LSP and emacs to use the correct Nix-y set of dependencies? To make things ex…

I have never tried Nix, but read about it a lot, and I agree that this part is most of the time completely glossed over in tutorials. I get that nix-shell is cool, and I can get the shell with everything configured to run, let's say, Python with specific deps, very easily - but... then what? Can I run, let's say, IDEA or vscode from there and get all the PATH stuff right? Or does it require extra magic? Not everyone lives and breathes in terminal (even though I mostly do).

Re: I think it's time to give Nix a chance

#67
This article felt like a strong argument against Nix rather than in favor of it. The complexity it brings is just not worth the gains for the majority of people that I know. No, most people won't be happy that Nix breaks dynamic linking.

Docker with a Debian Stable base will solve the problems listed for most users, with 1% of the time investment. The author used Nix for 8 years, and I'm not surprised it looks a bit simpler to them now.

Re: I think it's time to give Nix a chance

#68
Nix + flakes & direnv is the perfect dev environment, run it on the Mac and everybody in team can setup any project in seconds. We also have a makefile that sets up Postgres / init,start,stop with a local file socket - so every project instance has it’s own db instance. Very jummy.

That said I wish it was easier to be able to pick a specific build of for example ruby like ruby-3.3.7-p123.

Re: I think it's time to give Nix a chance

#69

An unexpected benefit of nix for me was CI caching. It’s easy to set up S3 as a binary cache, and then anything you can express as a nix derivation can be cached so that if nothing has changed, it avoids a build. One fun example is the test database: five years of accumulated migrations were relatively slow to run in various portions of the pipeline. I made a nix derivation that runs postgres, runs migrations, seeds…

Interesting, I have my own hacked together caches to greatly speed up docker setup, having a cache at this level may speed things up further in a cleaner more maintainable way.
Post reply on HN