Maybe I'm projecting my own experiences onto this, but the few times I've encountered "critical 25 year old code that can't be upgraded" situations they have always been badly neglected and knowledge about their workings is either already gone or concentrated in a few people about to retire.
No codebase has eternal life: sooner or later you need to upgrade the code anyway because some upstream vendor finally retired an API, or CPU vendor finally ran out of spare parts for the obscure architecture it was running on, regulation like GDPR means big changes are needed, etc etc etc. If you do the upgrades sooner, more of the domain knowledge that the original devs built up will still be around and upgrading will be relatively painless. If you delay until the last possible moment, you virtually guarantee that the upgrade will be as painful as possible. In the example, Nix being used as a bandaid to further delay upgrades is very likely going to lead to long term problems
IMO, any codebase that is critical to a business should always be in a state of partial rewriting/refactoring/upgrading, to keep it up-to-date but also just to keep the current devs familiar with how it all works. Institutional knowledge degrades over time otherwise and regular maintenance is way cheaper than the occasional massive blowup.
That said, nix has other benefits and it's merely this example that I have a problem with. Please don't use nix to excuse poor software maintenance practices, but use it for things it was meant for.
I suppose it depends on the application. NASA is still communicating with voyager, and being able to setup a build environment for the old protocols written 40 years ago on a modern computer would be quite valuable to them.
I imagine there are also still microcontroller systems that communicate via standardized protocols that don't need APIs of the kind you're thinking of. Say, like older nuclear power plants.
Everything has a shelf life, but a long lifetime doesn't necessarily mean a system has to constantly evolved/kept up to date in the manner you're describing. Being able to install an environment that's guaranteed to reproduce the original system as deployed would be valuable though, and Nix seems it could fit the bill.
Fair enough, there are definitely some applications where old does not mean out of date (mostly non-internet-connected applications I think). The original example in the article contained "It can’t be upgraded safely because the entire world’s banking system would fall apart if it did.", which definitely does seem like a disaster waiting to happen.
Nix seems like it could fill a niche, but I do wonder if it will be as ubiquitous as some articles proclaim. Certainly with the apps I currently work on (Ruby/Rails mostly) we already experience almost none of the pain that Nix claims to solve, so I doubt many will switch.
Source code and abstract virtual machines make many things easier. However, I expect Rails is typically deployed via Docker or something to capture dependencies. That part could be replaced by Nix, in principle.
People also use Nix quite in combination with Docker, so clearly Docker doesn't go far enough on the developer experience, and Nix doesn't provide isolation so Docker provides advantages from that side.
I feel like there should be a more integrated, comprehensive solution for this sort of thing, but these are on the right track.
No codebase has eternal life: sooner or later you need to upgrade the code anyway because some upstream vendor finally retired an API, or CPU vendor finally ran out of spare parts for the obscure architecture it was running on, regulation like GDPR means big changes are needed, etc etc etc. If you do the upgrades sooner, more of the domain knowledge that the original devs built up will still be around and upgrading will be relatively painless. If you delay until the last possible moment, you virtually guarantee that the upgrade will be as painful as possible. In the example, Nix being used as a bandaid to further delay upgrades is very likely going to lead to long term problems
IMO, any codebase that is critical to a business should always be in a state of partial rewriting/refactoring/upgrading, to keep it up-to-date but also just to keep the current devs familiar with how it all works. Institutional knowledge degrades over time otherwise and regular maintenance is way cheaper than the occasional massive blowup.
That said, nix has other benefits and it's merely this example that I have a problem with. Please don't use nix to excuse poor software maintenance practices, but use it for things it was meant for.