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

41–50 of 144 posts

Re: Why We're Moving on from Nix

#41

Post by bigyabai »

hu3 wrote: post #29
xvilka wrote: post #22

Earlier quoted context omitted.

Rust does the same.

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.

Re: Why We're Moving on from Nix

#42

Post by bithavoc »

xvilka wrote: post #22
Onavo wrote: post #21

Earlier quoted context omitted.

Go also statically links all dependencies and reinvents all the wheels usually provided by the system land. Cross compilation is trivial. It is unrivaled when it comes to deployment simplicity.

Rust does the same.

Rust can cross-compile, yes, but is not as seamless. For example, Rust can not cross-compile Windows binaries from Linux without external support like MinGW.

Go can cross-compile from Linux to Windows, Darwin and FreeBSD without requiring any external tooling.

Re: Why We're Moving on from Nix

#43

Post by setheron »

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…

Nix has support for bit reproduction and will not rebuild on comments if you specify it.

Of course lots of software isn't ready for but reproduction which is why Nix has taken such a pragmatic approach. (I have written a lot about this).

It's all a series of tradeoffs. If your goal is reproducibility (as close as you can get), you will have a larger graph likely ..since you are accounting for more!

Sometimes we like to believe we can have our cake and eat it too rather than understand life's a series of tradeoffs.

When we think we are getting a silver bullet, we've likely just pushed that complexity somewhere else.

Re: Why We're Moving on from Nix

#44

Post by mplanchard »

e3bc54b2 wrote: post #16
elbear wrote: post #6

Earlier quoted context omitted.

The version limits come from the fact that the Nix cache doesn't maintain older versions. So, if you use an older version, you will have to compile from sources. It sounds like they didn't want to take it upon themselves and provide a cache with older versions, even though it doesn't sound like much effort. Honestly, the reasons given don't feel very solid. Maybe the person who introduced Nix left and the ones remain…

Nix cache (cache.nixos.org) does in fact maintain older versions[0]. In fact, they maintain so much older stuff (binaries and associated source), that they are used in both research[1][2] and are having issues with gigantic cache size[3][4]. And yes, their reasoning implies NIH and just unfamiliarity combined with unwillingness to really understand Nix. [0]: https://discourse.nixos.org/t/how-long-is-binary-cache-kept…

Even if this weren’t true, setting up their own binary cache on S3 would have been trivial. It took me half a day to get it set up for our CI pipeline.

Re: Why We're Moving on from Nix

#45

Post by mplanchard »

cormacrelf wrote: post #9
lloydatkinson wrote: post #2

As someone with only a little experience with Nix, the points here don’t really seem right? > This approach isn’t clear or maintainable, especially for contributors unfamiliar with Nix’s version management. > For languages like Node and Python, we ended up only supporting their latest major version. What is not maintainable about this? That they need to make a list of available versions? So, can this not be automated…

From the article: > The way Nixpacks uses Nix to pull in dependencies often results in massive image sizes with a single /nix/store layer ... all Nix and related packages and libraries needed for both the build and runtime are here. This statement is kinda like “I’m giving up on automobiles because I can’t make them go forward”. This is one of the things Nix can do most reliably. It automates the detection of which r…

To be fair to the authors, this IS a problem, albeit one they phrased poorly, especially with building docker images via nix. The store winds up containing way more than you need (eg all of postgres, not just psql), and it can be quite difficult to patch individual packages. Derivations are also not well-pruned in my experience, leading to very bloated docker images relative to using a staged Dockerfile.

Image size isn’t something we’ve focused a lot on, so I haven’t spent a ton of time on it, but searching for “nix docker image size” shows it to be a pretty commonly encountered thing.

Re: Why We're Moving on from Nix

#46

Post by matthewbauer »

0xbadcafebee wrote: post #36
matthewbauer wrote: post #31

Earlier quoted context omitted.

Not sure on the exact take of the OP, but: Package maintainers often think in terms of constraints like I need a 1.0.0 - constraints are not always right (say pkg1==1.9.0 actually breaks things) - constraints of each dependency combined ends up giving very little degrees of freedom in constraint solving, so that you can’t in fact just take any pkg1 and use it - even if you can use a given version, your package may ha…

> Constraint solving is really difficult and while it’s a cool idea, I think Nixpkgs takes the right approach in mostly avoiding it. If you want a given version of a package, you are forced to take the whole package set with you. Thank you, I was looking for an explanation of exactly why I hate Nix so much. It takes a complicated use case, and tries to "solve" it by making your use-case invalid. It's like the Soylent…

I mean you can do it in Nix using overlays and overrides. But it won’t be cached for you and there’s a lot of extra fiddling required. I think it’s pretty much the same as how Bazel and Buck work. This is the future like it or now.

Re: Why We're Moving on from Nix

#47

Post by lkjdsklf »

0xbadcafebee wrote: post #36
matthewbauer wrote: post #31

Earlier quoted context omitted.

Not sure on the exact take of the OP, but: Package maintainers often think in terms of constraints like I need a 1.0.0 - constraints are not always right (say pkg1==1.9.0 actually breaks things) - constraints of each dependency combined ends up giving very little degrees of freedom in constraint solving, so that you can’t in fact just take any pkg1 and use it - even if you can use a given version, your package may ha…

> Constraint solving is really difficult and while it’s a cool idea, I think Nixpkgs takes the right approach in mostly avoiding it. If you want a given version of a package, you are forced to take the whole package set with you. Thank you, I was looking for an explanation of exactly why I hate Nix so much. It takes a complicated use case, and tries to "solve" it by making your use-case invalid. It's like the Soylent…

It’s not an invalid use case in nixpkgs. It’s kind of the point of package overlays.

It removes the “magic” constraint solving that seemingly never works and pushes it to the user to make it work

Re: Why We're Moving on from Nix

#48

Post by ris »

k__ wrote: post #14
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…

"the "bespoke version soup" attitude that language package managers encourage" Care to elaborate what that means and what the alternative is?

It's the idea that every application can near-arbitrarily choose a bespoke-but-exact mix of versions of every underlying package and assume they all work together. This is same attitude that leads to seemingly every application on planet earth needing to individually duplicate the work of reacting to every single dependabot update for their thousands of underlying packages and deal with the fallout of conflicts when they arise.

Packages in nixpkgs follow the "managed distribution" model, where almost all package combinations can be expected to work together, remain reasonably stable (on the stable branch) for 6 months receiving security backports, then you do all your major upgrades when you jump to the next stable branch when it is released.

Re: Why We're Moving on from Nix

#50

Post by cchance »

jchw wrote: post #23

Okay I'm a Nix enthusiast but you'll have to trust me when I say that I'm not criticizing them for moving away from Nix; it isn't that strong of an emotional attachment. However, I'm not really sure I understand some of these complaints and they really could use more explanation. For example: > The biggest problem with Nix is its commit-based package versioning. Only the latest major version of each package is availa…

Honestly this feels more like rail... wants to make their own version, hence a new railX lol
Post reply on HN