Comment by clvx | Hacker News Reader

Comment by clvx | Hacker News Reader

Parent Full thread

I feel Nix is eating their lunch. Even though Nix as a language could be tough, it's a simpler solution than Dagger. It provides a shell, almost complete reproducibility and isolation can be added through containers. Working with dependencies to build source code using nix is usually straightforward but having the right binary version that doesn't have the same love as major languages (i.e. terraform, flux, etc) is one thing Nix really needs to implement. Marcelo's package version search[1] is a way to discover the particular hash but then you need to explicitly use that nixpkgs version for that particular binary and do a lot of mental gymnastics in your nix files. Nix could implement a syntax where you define the package versions as attribute set and then internally does a discovery of the nixpkgs hash for that versions and installs it. Flox and DevBox follow this pattern but I don't see why you need and external tool where this can be embedded in Nix (the cli).

[1] http://lazamar.github.io/download-specific-package-version-w...

IMO dagger isn't really comparable to nix.

We tried to fit dagger where we had jenkins - not just for binary builds, but for the other stuff. Mounting secrets for git clones / NPM installs, integration tests, terraform execution, build notifications and logging.

Caching is great, and dagger/nix both have interesting options here, but that's more of a bonus and not the core value prop of a build orchestrator.

Yeah, turning a lot of our Jenkins Groovy into Dagger one-liners. Makes it super easy to "run" CI locally before pushing, but you still need the orchestrator / scheduler. Also really loving the Dagger Cloud UI for build logs over Jenkins UI

We tried to fit dagger where we had jenkins

"Tried", implying it didn't go well and isn't a fit for replacing Jenkins?

I've found the Nix ecosystem to be lacking, missing packages, wrongly built packages (from the official upstream), and out of date versions. Homebrew still outclasses Nix in this regard (quality over quantity).

After taking Nix for a spin, I cannot be bothered to learn another custom tool with a bespoke language when I already have containers for doing the same things.

For Dagger, I can choose from a number of languages I already know and the Docker concepts map over nearly 1-1

> I've found the Nix ecosystem to be lacking, missing packages, wrongly built packages (from the official upstream), and out of date versions. Homebrew still outclasses Nix in this regard (quality over quantity).

That's also the case with the Docker ecosystem. On top of that, you need to take into account the base image, versions, etc.

At the end what I look for is for a project being able to build my source code with runtime dependencies and supporting tools that won't change overtime for the architecture that I need.

these days, the nix vs alts debates remind me of the emacs vs alts debates of yore

I have not yet encountered actual nix usage in my professional or open source work, so I don't see Nix as eating anyone's lunch

I happen to know Nix, but it’s from previous experience where I also learned to greatly dislike it. Anyways, did an interview yesterday where the company was using Nix to build and they were completely shocked I had Nix experience.

So yeah, no where near eating anyone’s lunch, let alone the behemoth that is Docker.

This is an interesting take, especially since I've had exactly the opposite impression. Since you mention Homebrew, I assume you're talking about running Nix on macOS, which has been eye-opening for me. The ecosystem is much larger, I very rarely don't find what I'm looking for in nixpkgs, and if it's not there, it _definitely_ won't be in homebrew. I only use homebrew for casks nowadays (and even that is managed through nix). There's also been times when I've tried to install something from homebrew on a colleague's machine, and it was a huge pain to set it up correctly (having to manually install some dependencies) whereas everything worked without effort using nix. The only downside imho is that package authors tend to go for updating homebrew first if anything, since that's considered the default. Nix will typically get updated version a few days later, but that's fine for me.

Homebrew supports both Mac and Linux

I definitely encountered packages available in homebrew but not nixpkgs, so the idea that if not in nix not in brew is wrong. Another package I use has been out of date for months, again it's quality over quantity and nix lacks the quality that i deem more important for myself

Someone else published a nixpkg for my project, but it is wrong. As an OSS maintainer, I have reduced the number of places I publish, too many packages managers these days for my limited time

> I've found the Nix ecosystem to be lacking, missing packages, wrongly built packages

This is an interesting problem you've faced, their marketing claim is that they have the most comprehensive catalog of packages (and I'm inclined to believe it). I very rarely run into broken packages, and that's usually resolved by using a stable release for that specific package - and it's not like my usage of packages is lightweight (7292 lines of nix config). That's on NixOS (and Silverblue, and Ubuntu) at least.

That's on NixOS, but on other distros there are issues. When I tried nix last year, installing alacritty, for example, required an opengl wrapper. Neovim couldn't compile plugins without environment hackery.

Things just work with pacman or dnf.

The non-NixOS OpenGL/gpu story is unfortunately tricky as it requires a binary matchup between a userspace library and the kernel driver—which on non-NixOS is unknown to the Nix package manager since it's being managed by whatever the host is.

This is arguably a flaw in how Nvidia architected this, but it is what it is. The classical solution is nixGL [1], but this requires downloading special nixified versions of the libraries on every host system kernel change. An alternative option that I was involved in the development of is nix-gl-host [2], which manipulates the LD_LIBRARY_PATH for a Nix executable to allow it to link patched versions of the host's own userspace GL libraries.

[1]: https://github.com/nix-community/nixGL

[2]: https://github.com/numtide/nix-gl-host

Reply on news.ycombinator.com