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

Why We're Moving on from Nix

blog.railway.com

Post reply on HN
Print view View original

111–120 of 144 posts

Re: Why We're Moving on from Nix

#111

Post by gf000 »

Dylan16807 wrote: post #100
eddythompson80 wrote: post #63

Earlier quoted context omitted.

> The industry is full of ineptitude though. While I disagree with the person you're replying to, I find your reply dismissive. I don't know the behind-the-scnene reasons for this, but I can very very easily apply a very similar situation to this from my experience. Nix is a full blown functional programming language along with a very rich (and poorly documented, niche, only second to C++ template in error comprehens…

> maintaining 3 stacks, a Nix stack, a Go stack, and a Rust stack Nix is a package management system with a little bit of programming tucked onto the side. "Nix stack" is not the same type of thing as "Go/Rust stack". If you try to move things over to Go/Rust, you'll spend a little bit of time rewriting the code and a whole lot of time reinventing the wheel on everything else involved. You're not moving between imple…

But they also have to manage the Git stack on top of all that! /s

(Though really, what's up with so many people in the industry being absolutely bad at git well into their careers?!)

Re: Why We're Moving on from Nix

#112

Post by gf000 »

zxexz wrote: post #84
teekert wrote: post #7

Earlier quoted context omitted.

I feel it like that as well, but in some ways Nix is a more normal programming paradigm than other OS’s. We’re just not used to thinking about an OS that way. Nix expressions have inputs (a package repo, lots of key-value pairs) and outputs (a Linux system). Idk perhaps in a couple of years it will be much more normal. Ie it is very easy for an AI to create a to-spec shell.nix (some Python packages, some Linux packag…

I often find it takes about 10 minutes of my time to package your average python package into nix, or 1 minute if its pyproject.toml based (uv/poetry projects!. There is a long tail though ( cough weasyprint cough ).

That's mostly just a tooling issue/a paradigm mismatch. Python's package management is notoriously bad, so it sorta makes sense that it won't fit as nicely with Nix.

Re: Why We're Moving on from Nix

#113

Post by gf000 »

nialv7 wrote: post #18
setheron wrote: post #17

Nix gives you a commit guarantee rather than arbitrary versions. You're going to put yourself in a bad time when you have edge cases: glibc changes or conflicting shared libraries. It sounds like it's a little bit too late, but I'm happy to provide some consulting on how you can get it to work idiomatically with Nix. Product looks cool!

nix solves the shared library incompatibility problem by being extremely conservative. every time anything changes, consequential or not - a comment got modified, documentation changes, a testcase got added, etc. - it will rebuild all dependents. and not just that, but all dependents of dependents, and dependents of dependents of dependents, on and on. this often results in massive massive rebuilds. sure you are not…

I mean, there is no other way that guarantees correctness across arbitrary tools/functions/builds. Like, what if I have a step that replaces certain comments with code?

Also, the primary way to develop with Nix is to create your exact, reproducible environment in the form of a shell, and then develop there using the usual, language-idiomatic iterative way.

But now you can actually have a very specific compiler-flag for only a single dependency mixed with a full different libc working in a given shell 100%, for you and everyone else, instead of iterating through nodejs and npm version combination to start working on this new project, taking a couple of days..

Re: Why We're Moving on from Nix

#114

Post by gf000 »

smilliken wrote: post #40
nialv7 wrote: post #18

Earlier quoted context omitted.

nix solves the shared library incompatibility problem by being extremely conservative. every time anything changes, consequential or not - a comment got modified, documentation changes, a testcase got added, etc. - it will rebuild all dependents. and not just that, but all dependents of dependents, and dependents of dependents of dependents, on and on. this often results in massive massive rebuilds. sure you are not…

The reason someone changes a dependency at all is because they expect a difference in behavior. No one would feel the motivation to go update a dependency if they aren't getting something out of it, that's a waste of effort and an unnecessary risk. Each person doesn't have to perform the build on their own. A build server will evaluate it and others will pull it from the cache. The greater waste that nix eliminates i…

Yep, anyone not getting how absolutely huge the Nix model is should just install the whole KDE desktop, the Gnome desktop, and uninstall both. Only nix can make it basically a no-op.

Re: Why We're Moving on from Nix

#115

Post by nialv7 »

smilliken wrote: post #40
nialv7 wrote: post #18

Earlier quoted context omitted.

nix solves the shared library incompatibility problem by being extremely conservative. every time anything changes, consequential or not - a comment got modified, documentation changes, a testcase got added, etc. - it will rebuild all dependents. and not just that, but all dependents of dependents, and dependents of dependents of dependents, on and on. this often results in massive massive rebuilds. sure you are not…

The reason someone changes a dependency at all is because they expect a difference in behavior. No one would feel the motivation to go update a dependency if they aren't getting something out of it, that's a waste of effort and an unnecessary risk. Each person doesn't have to perform the build on their own. A build server will evaluate it and others will pull it from the cache. The greater waste that nix eliminates i…

> With NixOS, the upgrades are so reliable

Yeah they may be reliable _for you_. And do note this reliability doesn't come automatically with Nix's model, it is only possible because many people put a lot of effort into making it working correctly.

If you use the unstable channels, you would know. My NixOS upgrades break _all_ the time. On average, probably once a month.

Re: Why We're Moving on from Nix

#116

Post by cmrdporcupine »

jchook wrote: post #105

Fascinated by so many replies of "actually Nix does this just fine, you just have to be an expert like me"

Welcome to the world of Nix.

Just the latest in the line of "my totalizing world view will solve all your software problems" to which the answer of "this doesn't do what I want" is always "you're holding it wrong."

Re: Why We're Moving on from Nix

#117

Post by Guvante »

eddythompson80 wrote: post #68
whateveracct wrote: post #64

Earlier quoted context omitted.

I'm not being dismissive. Well, I am dismissing a lot of industry people's opinions. Because they're bad. Just because people decide stuff for money doesn't mean I can't call them bad. Not everyone is equally skilled. And your parable is exactly the issue. The unskilled and loud and whiny do often win, and it's a shame. I see it all the time. (Also you're way overstating Nix as a "full blown FP language." It isn't ha…

So you are being dismissive. That's what you're doing. You're dismissing more than just "stuff for money". You're dismissing anything that doesn't fall under the "skill" or "technical" category. All software projects contain a human element. I was showing an example from my experience on how something like that could happen. > A perfectly capably (but perhaps a bit esoteric) technology is picked by a smart passionate…

Two things can be true in your hypothetical:

1. Someone was forced to maintain Nix and want to switch to easier to maintain tooling 2. That someone can lack in technical understanding of the problems they are facing

The former doesn't negate the later.

The way I would put it is sometimes you choose a worse option because the people you have available are better at that option. That doesn't mean you made a mistake but it does mean your lack of expertise sent you down a different path.

And of course to finalize I will re-emphasize my "didn't make a mistake" comment. Ivory tower isn't a good idea either.

But someone responding "it is too bad the company that built packages couldn't properly use the package tooling they depended on" can still be true in a situation where a company made the correct decision of dropping that package tooling.

Re: Why We're Moving on from Nix

#118

Post by unshavedyak »

zxexz wrote: post #86
kesor wrote: post #11

Looks like they are trying to force versions into where there are none. Just like trying to force a square cube into a round hole. "Default versions" breaking things that depend on them? What is that? It is like using docker's ":latest" tag and being surprised each time that a new server falls on its face because the "default" image is actually a different version from the previous "default" image. I don't understand…

I’m all for not using nix, especially where it doesn’t make sense. But rebuilding a working system from scratch, for reasons that aren’t actually a problem if they were to have spent even a couple hours looking at how people already solve those issues, seems fundamentally insane. Like others have said here, nix2container and flakes seem like they would address every problem they have. With regard to versioning, I hav…

Yea, i kinda hate Nix - but it's fundamentally changed how i view OSs and the minimum features i want from them.

Though I really want another language than Nixlang, but i've been stuck on Nix for years despite not liking it because the concrete builds are just so good. If Nix actually had a language i liked i'd probably go full immutable user config too and fully embrace nix. It's just so, so good.

I'd switch in a heartbeat if someone iterated on Nix for some of my complaints, though. But i'm not switching away from the concrete system builds.. it's just amazing.

Re: Why We're Moving on from Nix

#119

Post by alexpotato »

In my experience as a DevOps/SRE, I feel like every time someone tries to have a system to manage dependencies etc, its goes one of two ways (I'll use Python as an example):

OPTION 1

"We'll have one big shared mono repo"

Pros:

- it's all in one place

- it's "batteries included"

- everyone uses the same one (so things like vulnerability issues are easy to fix)

Cons:

- someone always wants a special version

- hard to do tiered rollouts so changes tend to be big bang

- "But what about if we want to build a small docker version?"

OPTION 2

"Everyone gets their own conda/venv!"

Pros:

- Everyone gets exactly what they want

- Don't use packages they don't need

- Easy to upgrade in phases/tiers etc

Cons:

- "Wait, we have HOW MANY different conda environments??"

- Libraries from different groups may not be tested with the same Python libraries

- Vulnerability management is a nightmare b/c you don't even know were all of the different conda envs are.

The above is why I'm always skeptical of "This new way will fix it all!".

In short, "there are no solutions, only tradeoffs" gets more and more true the later I go in my career.

Post reply on HN