21–30 of 144 posts
> We also changed the codebase from Rust to Go because of the Buildkit libraries. Go is the best choice at the moment for such tools. These tools start a process, do lots of IO and exit. Very pragmatic choice.
> We also changed the codebase from Rust to Go because of the Buildkit libraries. Go is the best choice at the moment for such tools. These tools start a process, do lots of IO and exit. Very pragmatic choice.
Go also statically links all dependencies and reinvents all the wheels usually provided by the system land. Cross compilation is trivial. It is unrivaled when it comes to deployment simplicity.
> The biggest problem with Nix is its commit-based package versioning. Only the latest major version of each package is available, with versions tied to specific commits in the nixpkgs repo.
While Nixpkgs is an amazing resource, Nix != Nixpkgs. Nixpkgs is highly unideal for cases where you want to be able to pull arbitrary versions of toolchains, but it is not the only way to go. For example, there is amazingly good Nix tooling for pulling an arbitrary version of Rust. Other Nix-based developer tools have shown how you can do this well.
> no way of splitting up the Nix dependencies into separate layers
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.
> We also changed the codebase from Rust to Go because of the Buildkit libraries.
This part is not related to Nix, but I find it interesting anyways. Obviously most people don't transition programming languages on a whim, it's generally something you do when you're already planning on building from scratch anyways. To me it almost sounds like different people worked on Railpacks vs Nixpacks.
(I've definitely seen what happens when people not familiar with Nix wind up having to deal with unfinished Nix solutions within an organization. It is not pretty, as most people are unwilling to try to figure out Nix. I don't generally use Nix at work out of fear of causing this situation.)
I dont see why they couldnt made their own derivations instead of relying on nixpkgs hashes.
> Smaller Builds > Better caching
what were the benefits that overcame this, and what about those now?
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.
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…
What works better to raise VC (which for many is the goal) A nix wrapper or a deployment platform
I don't think any VC worth the time is going to sit around nitpicking how much Nix matters to their offering if they're making increasing amounts of money.
As 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 remain…
Earlier quoted context omitted.
Go also statically links all dependencies and reinvents all the wheels usually provided by the system land. Cross compilation is trivial. It is unrivaled when it comes to deployment simplicity.
Rust does the same.
Meanwhile Rust requires a pile of variable quality community driven crates to do basic things.
Earlier quoted context omitted.
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 remain…
Nix cache does provide old versions. What they seem to want is old versions built with new versions of dependencies. That's also possible, but you will have to build things.