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

11–20 of 144 posts

Re: Why We're Moving on from Nix

#11

Post by kesor »

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 any of the explanations in this blog post. Seems like people who have zero clue about what a "version" of a software is.

"no way of splitting up the Nix dependencies into separate layers" - Why? Of course you can split /nix/store into as many layers as you need. Do they even know how to use containers and how to use Nix in the first place?

With the clear incompetence of these people, no wonder that their proposed solution smells like a decomposed fish.

Classic NIH syndrome. There is going to be no surprise to see them meet the exact same problems they didn't solve with Nix to infest their new "solution".

Re: Why We're Moving on from Nix

#13

Post by jbverschoor »

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…

What works better to raise VC (which for many is the goal)

A nix wrapper or a deployment platform

Re: Why We're Moving on from Nix

#14

Post by k__ »

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?

Re: Why We're Moving on from Nix

#15

Post by droelf »

We've been working on Pixi, which uses Conda packages. You can control versions precisely and also easily build your own software into a package to ship it. Would be curious to chat if it could be useful as an alternative to `mise`.

Re: Why We're Moving on from Nix

#16

Post by e3bc54b2 »

elbear wrote: post #6
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…

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-...

[1]: https://hal.science/hal-04913007

[2]: https://luj.fr/blog/is-nixos-truly-reproducible.html

[3]: https://discourse.nixos.org/t/nixos-foundations-financial-su...

[4]: https://discourse.nixos.org/t/the-nixos-foundations-call-to-...

Re: Why We're Moving on from Nix

#17

Post by setheron »

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!

Re: Why We're Moving on from Nix

#18

Post by nialv7 »

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 going to get shared library conflicts, but i think this solution is extremely wasteful, and can make development painful too - look at nixpkgs' staging process.

Re: Why We're Moving on from Nix

#20

Post by wg0 »

> We also changed the codebase from Rust to Go because of the Buildkit libraries.

Go is the best choice at the moment for such tools. These tools start a process, do lots of IO and exit.

Very pragmatic choice.

Post reply on HN