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

81–90 of 144 posts

Re: Why We're Moving on from Nix

#81

Post by grep_name »

foooorsyth wrote: post #26

>The biggest problem with Nix is its commit-based package versioning. I am naive about Nix, but... ...isn't that like...the whole selling point of Nix? That it's specific about what you're getting, instead of allowing ticking time bombs like python:latest or npm-style glibc:^4.4.4 Odd to attach yourself to Nix then blog against its USP.

Eh. I've been using nixOS for years now and still find that I often desperately, desperately wish I could upgrade just one program that I need a new version of without risking that, you know, any individial single one of my installed packages has a change between the last update and now that messes up my workflow. Or that I could pin a version of a software that I'm happier with that version of without essentially rolling my own package repo. It is, in fact, the only package manager I'm aware of that makes it such a pain to do that. It's only because people in this thread are insisting it's doable that I say 'such a pain' instead of just 'impossible'.

A few weeks ago I needed to update firefox for a bug fix that was causing a crash, but of course that meant updating all of nixpkgs. When I finished the switch, the new version of pipewire was broken in some subtle way and I had to roll it back and have been dealing with firefox crashing once a week instead. I can't imagine pitching this to my team for development when I'm having this kind of avoidable issue just with regular packages that aren't even language dependencies.

To those who say 'if you want to lock your dependencies for a project, you can just build a nix flake from a locked file using the tools' I say, why the hell would I want to do that? Being able to manage multiple ecosystems from the same configuration tool was half the draw of nix in the first place!

Re: Why We're Moving on from Nix

#82

Post by baobun »

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…

I think the part that's easy to miss is that their users are devs who will want to specify their own dependencies and versions for arbitrary packages.

The way nix works with the way nixpkgs is structured, pinning a version of any package means pinning a commit of the entire nixpkgs tree. Since package builds of node/python/ruby packages depend on stuff outside of the package dir in the tree, you need that mapping between versions and commits. It is also a leaky abstraction, so they will need to expose that to their users, who now may run into situations where they need to align various states of the nixpkgs repo when they just wanted to "yarn add new-fancy-nodejs-package-with-linked–native-deps".

Using nix without nixpkgs may be fine for more scoped use but seems hard to justify for a platform like Railway.

Re: Why We're Moving on from Nix

#83

Post by Aurornis »

From the headline I thought they were making a single incremental change (Nix) but the article sounds like they’re doing an entire rewrite under a new project name:

> Since we transitioned away from Nix, we also transitioned away from the name Nixpacks in favor of Railpack. We also changed the codebase from Rust to Go because of the Buildkit libraries.

Suddenly the move away from Nix seems less like an incremental change and more like one part of a complete overhaul of the entire project. Did they have a team changeover or something? Or did they just want to start over from scratch and rewrite the whole project?

It also seems strange to switch to an entirely different programming language for a single library. I haven’t found library FFI to be a huge obstacle in Rust.

Re: Why We're Moving on from Nix

#84

Post by zxexz »

teekert wrote: post #7
mrbluecoat wrote: post #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 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 packag…

I often find it takes about 10 minutes of my time to package your average python package into nix, or 1 minute if its pyproject.toml based (uv/poetry projects!.

There is a long tail though (cough weasyprint cough).

Re: Why We're Moving on from Nix

#85

Post by chpatrick »

api wrote: post #59

Nix strikes me as an incredibly well thought out solution to a set of problems that should not exist. The OS should be immutable. Apps and services and drivers/extensions should be self contained. Things should not be installed “on” the OS. This entire concept is a trillion dollar mistake.

Well, what you're describing is NixOS.

Re: Why We're Moving on from Nix

#86

Post by zxexz »

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…

I’m all for not using nix, especially where it doesn’t make sense. But rebuilding a working system from scratch, for reasons that aren’t actually a problem if they were to have spent even a couple hours looking at how people already solve those issues, seems fundamentally insane.

Like others have said here, nix2container and flakes seem like they would address every problem they have.

With regard to versioning, I have flakes written 3 years ago that still build with exactly the same versions and the same output as when it was first written.

Sure does sound like that want to go to market and raise off a platform :D

Edit: Literally just checked nixpacks’ github and it immediately jumped out to me that they are using rustPlatform in nixpkgs, not oxalica’s rust-overlay[0] which would have come up in any cursory search for the rust issues. And is one of the most useful and powerful overlays I’ve used.

[0] https://github.com/oxalica/rust-overlay

Re: Why We're Moving on from Nix

#88

Post by gosub100 »

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…

> Nix != Nixpkgs

I've been told this when trying FreeBSD in regards to freebsd ports. pkg generally works fine for me, but one day I tried to go off the beaten path and compile vim with some custom USE flags (I forget what they are called in freebsd) in the ports section. It pulled down 20+ dependencies and each `make menuconfig` kept asking me "would you like any of these options" I selected a few that seemed reasonable, and lo-and-behold, package 16 out of 23 fails because "this-requires-that and that-needs-Fubar3.32.1 and Fubar3 is deprecated for Fubar4" and I just gave up. I get that the Core OS devs can't support all 10k+ packages, but they should also be very clear that if you actually try to use them (i.e. enable custom features, not just compile stock code) there's a high chance they won't work. Another option would be to yank them from the ports list if they don't compile and require at least some standard, independently-produced build to succeed before they appear in portsnap fetch.

Re: Why We're Moving on from Nix

#89

Post by fucker42069 »

grep_name wrote: post #81
foooorsyth wrote: post #26

>The biggest problem with Nix is its commit-based package versioning. I am naive about Nix, but... ...isn't that like...the whole selling point of Nix? That it's specific about what you're getting, instead of allowing ticking time bombs like python:latest or npm-style glibc:^4.4.4 Odd to attach yourself to Nix then blog against its USP.

Eh. I've been using nixOS for years now and still find that I often desperately, desperately wish I could upgrade just one program that I need a new version of without risking that, you know, any individial single one of my installed packages has a change between the last update and now that messes up my workflow. Or that I could pin a version of a software that I'm happier with that version of without essentially ro…

[dead]

Re: Why We're Moving on from Nix

#90

Post by trws »

dleslie wrote: post #52
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…

I don't use Nix, however this seems dismissive: > While Nixpkgs is an amazing resource, Nix != Nixpkgs. If Nixpkgs is the default and alternatives require additional research and effort then for most users it _is_ Nix. > That doesn't make any sense. You can literally just split them into separate layers in whatever arbitrary fashion you'd like. The built-in Nixpkgs docker tooling has some support for this even. Is th…

> Is this obvious, simple, and default behaviour?

Yes. There are two options IIRC, minimum layers and maximum layers (one per dep by default unless that makes too many, which is handled automatically) depending on what you want, and it’s a Boolean flag. If you need more control it’s more complicated but this one really is a strange criticism unless they’re using non-standard wrappers for the usual nix way to do this.

Post reply on HN