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

61–70 of 144 posts

Re: Why We're Moving on from Nix

#61

Post by nialv7 »

setheron wrote: post #43
nialv7 wrote: post #18

Earlier quoted context omitted.

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…

IIUC you are talking about CA-derivations? Yeah they may help but it's hard to know how much since it's not in production yet, despite being part of Eelco's original paper describing nix. So my hope isn't high.

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

True but we kind of just stopped looking. and I feel much of the solution space hasn't been explored.

Re: Why We're Moving on from Nix

#62

Post by internet_points »

jrockway wrote: post #57
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 this is pretty well stated. I'll add that while nixpkgs isn't nix, nixpkgs is kind of the good part. I use NixOS and for the first time in my life, I'm using the latest version of the Linux kernel on release day. That's pretty excellent. While I've come to tolerate Debian Stable in my old age, it is always like stepping a few years into the past ;) The Nix language is something I could criticize for hours wit…

> a Nix system always ends up being 1.4GB

That's strange, I never had problems building really tiny docker (release) images with nix, in fact it felt easier than doing it with alpine. You just get exactly what you specify, no more.

(OTOH, when developing in nix, I always end up with a huge /nix/store and have no idea how to clean it without garbage collecting everything and having to wait all over)

Re: Why We're Moving on from Nix

#63

Post by eddythompson80 »

whateveracct wrote: post #56
dleslie wrote: post #52

Earlier quoted context omitted.

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…

Nixpkgs isn't Nix and in production you rarely just use Nixpkgs verbatim. It's trivial to overlay whatever versions you want (including forks), and I'd say it's expected for any company in production to manage their package set. We are talking about a company full of professionals. If they need something obvious, simple, and default to manage their build - the core business function that turns their text into deploya…

> The industry is full of ineptitude though.

While I disagree with the person you're replying to, I find your reply dismissive.

I don't know the behind-the-scnene reasons for this, but I can very very easily apply a very similar situation to this from my experience.

Nix is a full blown functional programming language along with a very rich (and poorly documented, niche, only second to C++ template in error comprehensibility[1]) ecosystem in itself. It's not like "docker" or "kubernetes" where you're mostly dealing with "data" files like yaml, json or Dockerfile. You're dealing with a complex programming project.

With that in mind:

- You have a core team with 1 or 2 people with Nix passion/expertise.

- Those people do most of the heavy lifting in implementation.

- They onboarding the team on to Nix

- They evangelize Nix through the org/company

- They mod and answer all the "#nix-discussions" channel questions

Initially the system is fairly successful and everything is good. over the next 5-6 years it would accumulate a lot of feature asks. The original "Nix person" has long left. Most of the original people have moved either to other projects or not particularly that passionate about Nix. In fact, the "best" developer you have who has inherited the whole Nix thing has only really had to deal with all the shit parts of Nix and the system. They are they ones fixing issues, dealing with bugs, etc. All while maintaining 3 stacks, a Nix stack, a Go stack, and a Rust stack.

Eventually that person/team that's annoyed by maintaining the Nix project wins. They want to own that code. They don't want to use Nix any more. They know what's needed, they want to implement it as part of their main Go stack that they are actively working on. They can optimize things for their special case without having to worry about "implementing it the Nix way" or "doing it upstream".

They promise you (the management who is open to the idea, but trying to understand the ROI) feature parity + top 5 feature asks for the initial release. You trust the team enough to let them do what they think is best.

[1]: LLMs are really good at suggesting a solution given an error message. Nix errors bring them to their knees. It's always "Hmmm.... it appears that there is an error in your configuration... have you tried a `git revert`?"

Re: Why We're Moving on from Nix

#64

Post by whateveracct »

eddythompson80 wrote: post #63
whateveracct wrote: post #56

Earlier quoted context omitted.

Nixpkgs isn't Nix and in production you rarely just use Nixpkgs verbatim. It's trivial to overlay whatever versions you want (including forks), and I'd say it's expected for any company in production to manage their package set. We are talking about a company full of professionals. If they need something obvious, simple, and default to manage their build - the core business function that turns their text into deploya…

> The industry is full of ineptitude though. While I disagree with the person you're replying to, I find your reply dismissive. I don't know the behind-the-scnene reasons for this, but I can very very easily apply a very similar situation to this from my experience. Nix is a full blown functional programming language along with a very rich (and poorly documented, niche, only second to C++ template in error comprehens…

I'm not being dismissive. Well, I am dismissing a lot of industry people's opinions. Because they're bad.

Just because people decide stuff for money doesn't mean I can't call them bad. Not everyone is equally skilled.

And your parable is exactly the issue. The unskilled and loud and whiny do often win, and it's a shame. I see it all the time.

(Also you're way overstating Nix as a "full blown FP language." It isn't hard to learn. I learned it just be existing on a project with it. Within 6mo, now I'm apparently a "Nix expert" and people now point at me as one of the people who "knows it" and "you can't expect everyone to know it like you do." idk maybe I'm some genius but I think it's more that I just don't have a bad personality.)

Re: Why We're Moving on from Nix

#65

Post by eddythompson80 »

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!

> You're going to put yourself in a bad time when you have edge cases: glibc changes or conflicting shared libraries.

I totally understand the value proposition of Nix. However I think saying "bad time" is a bit hyperbolic. At most it's "You'll be losing a pretty significant guarantee compared to Nix". Still probably "packed to be more likely to work correctly" than 95% of software out there.

Re: Why We're Moving on from Nix

#66

Post by nothrabannosir »

kfajdsl wrote: post #60
dleslie wrote: post #52

Earlier quoted context omitted.

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…

This isn’t “most users”, this is a large company building a product on top of Nix. I’m pretty sure most orgs using Nix at a minimum have a custom overlay. If you identify these things as an issue, any competent engineer should find a variety of solutions with search and/or LLM assistance within an hour, since they’re not super obscure requirements. I’m not saying Railway didn’t do this and realize that these common s…

To emphasize this point: dleslie's comment is valid on a blog post "we tried Nix for a while to manage our dependencies, we are just building an app and want builds to work, and we decided to move on". For an end user, it is absolutely understandable to assume "nix = nixpkgs".

But as kfajdsl points out: that's not what TFA is. This is a company building a product on top of Nix. Package management is their expertise. Anyone using Nix in that capacity understands the distinction between nix and nixpkgs. Which they certainly do--GP only remarked it was odd they didn't explain it, not that they didn't know.

Re: Why We're Moving on from Nix

#67

Post by chriswarbo »

James_K wrote: post #53
k__ wrote: post #14

Earlier quoted context omitted.

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

Put out fewer versions of things. It is entirely possible to write a piece of software and only change the interface of it at rare intervals. The best solution I can think of though would be to allow one version of a package to provide multiple versions of its interface. Suppose you want to increment the minor version number of your code and this involves changing the signatures of a number of functions, you could de…

That's why everything in Nixpkgs is defined as a function, which takes dependencies as arguments.

It also puts a function in the result, called `override`, which can be called to swap out any of those arguments.

Re: Why We're Moving on from Nix

#68

Post by eddythompson80 »

whateveracct wrote: post #64
eddythompson80 wrote: post #63

Earlier quoted context omitted.

> The industry is full of ineptitude though. While I disagree with the person you're replying to, I find your reply dismissive. I don't know the behind-the-scnene reasons for this, but I can very very easily apply a very similar situation to this from my experience. Nix is a full blown functional programming language along with a very rich (and poorly documented, niche, only second to C++ template in error comprehens…

I'm not being dismissive. Well, I am dismissing a lot of industry people's opinions. Because they're bad. Just because people decide stuff for money doesn't mean I can't call them bad. Not everyone is equally skilled. And your parable is exactly the issue. The unskilled and loud and whiny do often win, and it's a shame. I see it all the time. (Also you're way overstating Nix as a "full blown FP language." It isn't ha…

So you are being dismissive. That's what you're doing. You're dismissing more than just "stuff for money". You're dismissing anything that doesn't fall under the "skill" or "technical" category. All software projects contain a human element. I was showing an example from my experience on how something like that could happen.

> A perfectly capably (but perhaps a bit esoteric) technology is picked by a smart passionate person for a project.

> The novel technology is in 1 isolated module that's mostly feature complete for the first 1-3 years.

> People in the team/company deal with that "thing" as a blackbox more and more

> 5-10 years later, mostly new team maintaining the project. They hate the weird choice of tech. "Why is only this one component different???"

> People understand the contract with the "black box" very well, but HATE the "black box". People think "We can implement the black box contract very easily"

Re: Why We're Moving on from Nix

#69

Post by schlarpc »

lewo wrote: post #35

> With no way of splitting up the Nix dependencies into separate layers nix2container [1] is actually able to do that: you can explicitly build layers containing a subset of the dependencies required by your image. An example is provided in this section: https://github.com/nlewo/nix2container?tab=readme-ov-file#is... For instance, if your images use bash, you can explicitly create a layer containing the bash closure.…

Just wanted to say thanks for nix2container. I’ve been using it to do some deploys to AWS (ECR) and my iteration time between builds is down to single digit seconds.

Re: Why We're Moving on from Nix

#70

Post by James_K »

chriswarbo wrote: post #67
James_K wrote: post #53

Earlier quoted context omitted.

Put out fewer versions of things. It is entirely possible to write a piece of software and only change the interface of it at rare intervals. The best solution I can think of though would be to allow one version of a package to provide multiple versions of its interface. Suppose you want to increment the minor version number of your code and this involves changing the signatures of a number of functions, you could de…

That's why everything in Nixpkgs is defined as a function, which takes dependencies as arguments. It also puts a function in the result, called `override`, which can be called to swap out any of those arguments.

Which leads to the exact problems defined in this article. Many programs using many library versions. It would be much better from both a security and size perspective if these disparate packages could be served by a single shared object using versioned symbols.
Post reply on HN