> 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.
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 solutions weren’t viable for them, but it’s odd to not mention anything they tried to get around it.
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.
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 deployable artifacts - maybe there is a skill culture issue.
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`?"
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.)
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"
1. Someone was forced to maintain Nix and want to switch to easier to maintain tooling
2. That someone can lack in technical understanding of the problems they are facing
The former doesn't negate the later.
The way I would put it is sometimes you choose a worse option because the people you have available are better at that option. That doesn't mean you made a mistake but it does mean your lack of expertise sent you down a different path.
And of course to finalize I will re-emphasize my "didn't make a mistake" comment. Ivory tower isn't a good idea either.
But someone responding "it is too bad the company that built packages couldn't properly use the package tooling they depended on" can still be true in a situation where a company made the correct decision of dropping that package tooling.
Yes I am dismissing. People don't have a right to not be dismissed if I judge them poorly. People are allowed to have bad professional opinions of others.
And I am dismissing the types you describe specifically. I dismiss them (privately amongst the likeminded) at work all the time too. I just put them on a list in my head when they start spouting these sorts of bad values.
> maintaining 3 stacks, a Nix stack, a Go stack, and a Rust stack
Nix is a package management system with a little bit of programming tucked onto the side. "Nix stack" is not the same type of thing as "Go/Rust stack". If you try to move things over to Go/Rust, you'll spend a little bit of time rewriting the code and a whole lot of time reinventing the wheel on everything else involved. You're not moving between implementations, you're building your own implementation. That's almost always a bad idea, and it's a much higher cost than learning the syntax.
Moving from a Nix stack to a Go stack only makes slightly more sense than moving from a docker stack to a Go stack. Which is to say, very little sense.
Wow, this is literally the story of my team. Luckily there’s enough autonomy for us the escape the gravitational pull of the few remaining evangelists, but this is essentially what led us to this point.
I think that's kind of sad. There are a lot of good technologies that require some investment to understand them and a lot of worse is better approaches that end in a mayhem that is ultimately a terrible work environment.
For a while it seemed like investment would win but now I think we will have massive tombs of poorly written stuff that can only be worked around with even more LLM generated solutions. It is like the software bloat problem we've had recently but on steroids.
In the documentation[0] they're right next to each other, and `buildImage`[1] (builds a single layer) specifically calls out that you probably want to use `buildLayeredImage` or `streamLayeredImage`[2] (both produce a separate layer per dependency) instead.
Neither should cause the final image to include build dependencies, that sounds like they were doing something silly like running `nix-build` from inside a Dockerfile and just taking that as their final image. Which.. yes, would include build cruft. Oh,[3] I guess that was exactly what they were doing after all. And mixing in Debian packages... for reasons, I guess.
> If Nixpkgs is the default and alternatives require additional research and effort then for most users it _is_ Nix.
This is not what parent commenter is getting at. Nix itself is a deterministic build tool. There is also a package manager built on top which uses a large collection of nix files to describe each package - this is nixpkgs.
They use the same primitives, but the same way you don't just yolo your node/rust etc build versions to whatever your OS comes with and use a lock file, you also want to have more control over the exact versions and thus may use something other than what nixpkgs packages. Especially that it makes it easy to override any property of your dependencies, unlike any other tool out there.
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.
> If Nixpkgs is the default and alternatives require additional research and effort then for most users it _is_ Nix.
This feels rather dismissive. They wrote a bespoke solution, not a weekend toy. Surely you'd agree that they have more than just surface-level knowledge of Nix, to be able to distinguish between Nix and Nixpkgs? They're already doing non-trivial things by merging multiple commits of Nixpkgs in order to get different versions of different tools!
> Is this obvious, simple, and default behaviour?
Well, Nix doesn't do much of anything "by default", it's a pretty generic tool. But insofar as it matters, Yes, pretty much. `dockerTools.buildLayeredImage` will in fact automatically build a layered image, and it is the most "obvious" way (IMO) to build a docker image. There is also `dockerTools.buildImage` but there's no particular reason to use it unless you specifically want a flattened image. (The documentation available is clear enough about this. In fact, in practice, much of the time you'd probably actually want `dockerTools.streamLayeredImage` instead, which is also documented well enough, but that's beyond the point here.)
But that's not my point. As far as I know, Nixpacks don't even use this functionality, I'm pretty sure they wrote their own OCI image building tools. And in that sense, it is not obvious why they can't split the Nix store and the article doesn't explain it.
My point wasn't to be dismissive about the difficulties of Nix, it's that the blog post doesn't really do a good job of explaining things. It makes it sound like these are normal problems in Nix, but they are not; even the official Nixpkgs documentation often points to third party solutions for when you're working outside of Nixpkgs, since most of the Nixpkgs tools is geared for Nixpkgs and NixOS usage. As an example, take a look at this section of the Rust documentation in Nixpkgs:
So even if you're relatively new to Nix, as long as you are reading the documentation you will indeed definitely be aware of the fact that there is more to the Nix ecosystem than just Nixpkgs. It may not be surface-level Nix knowledge, but it's certainly close.
> 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 this obvious, simple, and default behaviour?