[verdverm]

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

[clvx]

> 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.

[verdverm]

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

[sepositus]

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.

[kiliankoe]

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.

[verdverm]

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

[zamalek]

> 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.

[mmgutz]

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.

[mikepurvis]

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