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

71–80 of 144 posts

Re: Why We're Moving on from Nix

#71

Post by chriswarbo »

internet_points wrote: post #62
jrockway wrote: post #57

Earlier quoted context omitted.

I think this is pretty well stated. I'll add that while nixpkgs isn't nix, nixpkgs is kind of the good part. I use NixOS and for the first time in my life, I'm using the latest version of the Linux kernel on release day. That's pretty excellent. While I've come to tolerate Debian Stable in my old age, it is always like stepping a few years into the past ;) The Nix language is something I could criticize for hours wit…

> a Nix system always ends up being 1.4GB That's strange, I never had problems building really tiny docker (release) images with nix, in fact it felt easier than doing it with alpine. You just get exactly what you specify, no more. (OTOH, when developing in nix, I always end up with a huge /nix/store and have no idea how to clean it without garbage collecting everything and having to wait all over)

> I always end up with a huge /nix/store and have no idea how to clean it without garbage collecting everything and having to wait all over

FYI you can avoid things getting garbage-collected by doing `nix-store --add-root`; that makes an "(indirect) garbage collector root"[0]. Especially useful if you're using import-from-derivation, since that imported derivation won't appear in the dependencies of your final build output (which, to be clear, is a good thing; since it lets us calculate a derivation, e.g. by solving dependency constraints or whatever, without affecting the eventual hash if that calculation happens to match a previous one!)

[0] https://nix.dev/manual/nix/2.18/package-management/garbage-c...

Re: Why We're Moving on from Nix

#72

Post by whateveracct »

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…

Yes I am dismissing. People don't have a right to not be dismissed if I judge them poorly. People are allowed to have bad professional opinions of others.

And I am dismissing the types you describe specifically. I dismiss them (privately amongst the likeminded) at work all the time too. I just put them on a list in my head when they start spouting these sorts of bad values.

Re: Why We're Moving on from Nix

#73

Post by chriswarbo »

James_K wrote: post #70
chriswarbo wrote: post #67

Earlier quoted context omitted.

That's why everything in Nixpkgs is defined as a function, which takes dependencies as arguments. It also puts a function in the result, called `override`, which can be called to swap out any of those arguments.

Which leads to the exact problems defined in this article. Many programs using many library versions. It would be much better from both a security and size perspective if these disparate packages could be served by a single shared object using versioned symbols.

Hmm, not sure I agree. Most of those arguments get populated by taking the fixed-point, along with any given overlays; so it's easy to swap-out a library everywhere, just by sticking in an overlay. The exceptions mostly seem to be things that just don't work with the chosen version of some dependency; and even that's quite rare (e.g. it's common for Nixpkgs maintainers to patch a package in order to make the chosen dependency work; though that can causes other problems!)

Re: Why We're Moving on from Nix

#74

Post by hu3 »

bigyabai wrote: post #41
hu3 wrote: post #29

Earlier quoted context omitted.

Yea and at least Go provides a giant Google engineering tier quality standard library so reinventing the wheel here doesn't hurt so much productivity. Meanwhile Rust requires a pile of variable quality community driven crates to do basic things.

Both languages have enormous cargo-culting issues when you try to do anything that isn't fizzbuzz. The bigger difference that I'd expect people to identify is that Rust generates freestanding binaries where Go software requires a carefully-set runtime. There are pros and cons to each approach.

None of them generate true freestanding executables by default. Both Go and Rust require glibc.

And Go's runtime is built-in by default. Unlike Java so there's nothing to "carefully set".

Re: Why We're Moving on from Nix

#76

Post by bigyabai »

hu3 wrote: post #74
bigyabai wrote: post #41

Earlier quoted context omitted.

Both languages have enormous cargo-culting issues when you try to do anything that isn't fizzbuzz. The bigger difference that I'd expect people to identify is that Rust generates freestanding binaries where Go software requires a carefully-set runtime. There are pros and cons to each approach.

None of them generate true freestanding executables by default. Both Go and Rust require glibc. And Go's runtime is built-in by default. Unlike Java so there's nothing to "carefully set".

By that definition, I cannot name a single high-level programming language that generates freestanding binaries.

Re: Why We're Moving on from Nix

#79

Post by hu3 »

bigyabai wrote: post #76
hu3 wrote: post #74

Earlier quoted context omitted.

None of them generate true freestanding executables by default. Both Go and Rust require glibc. And Go's runtime is built-in by default. Unlike Java so there's nothing to "carefully set".

By that definition, I cannot name a single high-level programming language that generates freestanding binaries.

Many of them can, including Rust and Go. Just not with default arguments. You need to pass linking arguments.

This is not done by default to reduce binary sizes.

Re: Why We're Moving on from Nix

#80

Post by jorams »

ris wrote: post #10

The main problem here is wanting to hang on to the "bespoke version soup" attitude that language package managers encourage (and is totally unsustainable). The alternative Mise doesn't appear to have any ability to understand version constraints between packages and certainly doesn't run tests for each installed package to ensure it works correctly with the surrounding versions. So you're not getting remotely the sam…

Bespoke version soup is unsustainable, but part of why people keep doing it is that it tends to work fine. It tends to work fine in part because OS-level libraries come from a different, much more conservative world, in which breaking backwards compatibility is something you try to avoid as much as possible.

So they can take a stable, well-managed OS as a base, use tools like mise and asdf to build a bespoke version soup of tools and language runtimes on top, then run an app on top of that. It will almost never break. When it does break, they fiddle with versions and small fixes until it works again, then move on. The fact that it broke is annoying, but unimportant. Anything that introduces friction, requires more learning, or requires more work is a waste of time.

Others would instead look for a solution to stop it from breaking ever again. This solution is allowed to introduce friction, require more learning, or require more work, because they consider the problem important. These people want Nix.

Most people are in the first group, so a company like Railway that wants to grow ends up with a solution that fits that group.

Post reply on HN