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

I think it's time to give Nix a chance

maych.in

Post reply on HN
Print view View original

71–80 of 156 posts

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

#71

Post by pjmlp »

zylent wrote: post #61
pjmlp wrote: post #45

Earlier quoted context omitted.

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.

From those I only know Google and replit, which is still kind of unicorn, and most businesses will never be 1% of Google size.

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

#72

Post by pjmlp »

watusername wrote: post #63
pjmlp wrote: post #45

Earlier quoted context omitted.

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 Ru…

Yeah, but I would I want to advocate that to customer IT teams that never saw it on their lives, wish them good luck and jump ship?

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

#73

Post by packetlost »

sepositus wrote: post #21
urlwolf wrote: post #2

I moved to nix around Nov last year and couldn't be happier, the motto 'nix fixes that' is true. First time I can say linux is trouble free. Upgrades are painless. Dev environments, reproducible. Largest repository of packages in the linux world. Next to zero time wasted configuring things. Foundation LLMs now know enough nix to get you out of trouble most of the time. It's perfect as a linux experience.

Welcome to the honeymoon phase. Mine lasted about a year. Eventually you will have to leave the comfortable area of "those who have done it before" and engage with some long, unwieldy, mostly undecipherable stack trace. When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.

Been there. Powered through it. It gets easier when you actually read the Nix manual.

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

#74

Post by sshine »

bigyabai wrote: post #8
TeeMassive wrote: post #4

Earlier quoted context omitted.

Until your use case hasn't been deciphered by a Nix scribe and then you have to fight the magic.

I guess relentlessly dylibbed software like AppImage is the elephant in the room. Nix struggles to handle those types of programs, but they tend to work fine in Flatpak or with a special tool (eg. appimage-run or steam-run).

Struggle how?

There’s an entirely mechanical workflow for calling patchelf when packaging a binary that was compiled dynamically against library paths outside of the Nix store.

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

#75

Post by Tractor8626 »

Wow.

1) you can python environment with dependencies! (can do that without nix)

2) you can pin dependencies by hash! (can be done with any tool mentioned in article: docker, pip, npm etc)

If you can't make reproducible dev environment in 2025 - it is 100% skill issue.

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

#76

Post by corndoge »

Tractor8626 wrote: post #75

Wow. 1) you can python environment with dependencies! (can do that without nix) 2) you can pin dependencies by hash! (can be done with any tool mentioned in article: docker, pip, npm etc) If you can't make reproducible dev environment in 2025 - it is 100% skill issue.

For 1), how?

I'm specifically interested in how you handle packages that use C extensions that link system libraries.

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

#77

Post by davidcox143 »

nextos wrote: post #38
sepositus wrote: post #21

Earlier quoted context omitted.

Welcome to the honeymoon phase. Mine lasted about a year. Eventually you will have to leave the comfortable area of "those who have done it before" and engage with some long, unwieldy, mostly undecipherable stack trace. When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.

I think Nix is getting an unfair reputation for being too hard. Simple things are IMHO simpler in Nix than in any other distribution, and what one needs to know to accomplish them is tiny. It has basically reduced my sysadmin maintenance tasks to zero. In case of regressions, Nix makes it trivially easy to go back in time 2 or 3 years, cherrypick some packages and install them, or change your entire desktop environme…

I've been using Nix and NixOS since 2022. I can't imagine not using Nix at this point and agree that the reputation for "being too hard" is not quite accurate. Nix is different - that's the point.

The learning curve is a thing, although I'd argue that it's nowhere near as steep as the tools many of us use every day (C++, Rust, AWS/GCP, etc.)

Nix's "difficulty" IMO comes from defaults that are not sane and a split community. For example, if you use the official Nix installer, flakes are not enabled by default (despite being widely used [1]), but they are if you use the Determinate Systems Nix installer.

Flakes are realistically the only way to obtain the benefits that motivate learning Nix (deterministic pure builds, fine-grained control over dependencies) and are the "primary driver of Nix's adoption" [2]. AFIK there isn't a viable alternative to flakes other than maybe atoms [3], which are relatively new (like "lock files are totally hand made" new [4]). Yet, the official Nix stance on flakes is to wait... for... what?

For a day-in-the-life look at more of Nix's rough edges, I posted some rambles here [5].

[1] https://x.com/d4r5c2/status/1896415101386928539 [2] https://x.com/grhmc/status/1896551138104844389 [3] https://x.com/nrdexp/status/1925892763301695978 [4] https://x.com/nrdexp/status/1925707692447871283 [5] https://youtu.be/TwVamLq5OHY

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

#78

Post by PaulDavisThe1st »

What problem(s) does Nix solve that macOS's .app format does not? For that matter, that ad-hoc Linux packaging solutions involving LD_LIBRARY_PATH and included dependencies?

Put differently, doesn't the fundamental complexity of Nix come down to the combination of (a) "every app should get its own dependencies" and (b) "don't include dependencies with each app" ?

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

#79

Post by zoogeny »

Nix falls into the camp in my mind that includes Rust: great idea that I just don't have time for right now.

Reproducibility is the holy grail, IMO. It is so valuable that any system that actually achieves it will find some longevity and eventually be hammered into a useable form. I believed in the promise when AWS was all about amis. Then I believed in the promise with docker. It seems something like Nix is a natural next step in this evolution.

I want it to succeed enough that it gets easy enough for me to use. But for now I'll stick with macOS for my laptop and docker with alpine for my deployments.

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

#80

Post by strobe »

spenczar5 wrote: post #12

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…

In most cases is enough to have emacs installed as part of OS with all required general cli tools and then open project specific shell with all project dev dependencies like compilers and libs.

However is some cases when it could be little more tricky, for instance I'm using LSP for Scala (https://scalameta.org/metals/) which on start trying to automatically detect JDK version for project from environment. So if my project depends on JDK 11 it might required for me manually start LSP from nix-shell to force it use right JVM version.

With Rust is in someway similar, I need to bring some shell with 'rust up' setup so it could install everything for rust-analyzer then emacs can use it.

Regardless emacs itself is few options to manage emacs packages in nix way but for me it not really gives anything so I just use it as on any other OS.

Post reply on HN