Why We're Moving on from Nix
blog.railway.com
Why We're Moving on from Nix
1–10 of 144 posts
Re: Why We're Moving on from Nix
#2As 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?
Furthermore, why is Railway defining how a user uses Nix?
Surely one of the points of Nix is that you can take a bare machine and have it configured with exactly what versions of packages you want? Why would Railway need to get in the way of the user and limit their versions anyway?
Or did I misunderstand and they don’t even expose Nix to the user? If so, the original question still stands: can’t they automate that list of package versions?
Re: Why We're Moving on from Nix
#3As 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…
> Or did I misunderstand and they don’t even expose Nix to the user?
That's at least my understanding, yes.
Re: Why We're Moving on from Nix
#4As 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…
you can not have a dockerfile in your project at all, push your code to them, and they’d build an image for it with nixpacks. you’d see nix stuff in your build logs, but it’s behind the scenes for the most part.
Re: Why We're Moving on from Nix
#5> we don’t have any problem with Nix itself. But there is a problem with how we were using it.
A good example of 'use the right tool for the right job'. Nix is great for some use cases and awful for others. The problem is the Nix learning curve is so high that by the time you've grasped it enough to make a decision you feel you've invested too much time to back out now and pivot to something else so you try to shoehorn it to solve the original need.
Re: Why We're Moving on from Nix
#6As 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 remaining didn't like it very much (the language itself is not very nice, the docs weren't great either in the past).
Still, I'm not familiar enough with the stack they chose, but does it provide a level of determinism close to Nix? If not, it might come to bite them or make their life harder later on.
Re: Why We're Moving on from Nix
#7> we don’t have any problem with Nix itself. But there is a problem with how we were using it. A good example of 'use the right tool for the right job'. Nix is great for some use cases and awful for others. The problem is the Nix learning curve is so high that by the time you've grasped it enough to make a decision you feel you've invested too much time to back out now and pivot to something else so you try to shoeho…
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 packages, some env vars, some path entries etc), or configuration.nix because of this paradigm.
I do this a lot to include envs with repos that fully support the package. It would probably be more reproducible with flakes (a flake.nix is like a shell.nix but with version pinning… or something, I’m still climbing that learning hill).
Re: Why We're Moving on from Nix
#8The version selection part sounds weird. The versions in nixpkgs make sense when you're running/building the system. If you're providing runtimes/compilers as a platform, you really want something like what devenv does - provide the versions yourself. You really don't want to end up building an old system to provide an old nodejs - you're leaving security patches in dependencies behind. Devenv does it for example through https://github.com/cachix/nixpkgs-python "All Python versions, kept up-to-date on hourly basis using Nix."
> Railway injects a deployment ID environment variable into all builds.
They could've done it in the next layer after installation. Also, you can split packages into different layers. There's even automation for it if you need batches to keep the number of layers down.
Re: Why We're Moving on from Nix
#9As 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 runtime dependencies are actually referenced in the resulting binary, using string matching on /nix/store hashes. If they couldn’t make it do that, they’re doing something pretty weird or gravely wrong. I wouldn’t even know where to start to try to stop Nix from solving this automatically!
I wouldn’t read too much into their experience with it. The stuff about versioning is a very normal problem everyone has, would have been more interesting if they attempted to solve it.
Re: Why We're Moving on from Nix
#10The 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 same thing.