[flexiondotorg]

Closing in on 20 years of existence doesn't really qualify for fad

I'm just starting a serious learning journey with Nix after flirting with the idea for a few years. Mostly because I find myself endlessly working on tooling to support the projects I work on that Nix already does extremely well.

The feature I am most sold on is the ability to invoke clean complex development environments, that bring themselves to existence automatically as I traverse directories. If you work in code or in DevOps, Nix is totally worth a look.

[throwaway894345]

It may not be a fad, but there's a lot of rose-colored hype that masks a world of tedium. New prospective users should be prepared for a lot of uphill grind with respect to configuring packages or defining their own packages. Every time I try to do seemingly simple tasks in Nix, I end up spending hours on the Nix discord channel trying to work out a solution with seasoned users (who invariably struggle to work out a reasonable solution). Often times I end up having to try to figure out how to package some obscure C dependency deep in the dependency tree with its own bespoke build system and so on. Nixpkgs is also pretty poorly organized (or at least I can almost never find the package I need) and this is pretty critical because something as simple as answering "what type does this function take?" requires a ton of searching around Nixpkgs (largely due to the lack of type annotations or even informal documentation). The CLI tool surface is also not particularly intuitive, and there are different tools for different problems and no consensus about which tools to use (or at least the official docs often disagree with popular opinions in the community). You have to be aware of whether you're just using the Nix package manager or whether you're using NixOS because it will affect the way you write your configuration and often snippets on the Internet implicitly assume one or the other such that you will spend a lot of time trying to fix snippets or find the right snippet for your use case. MacOS is still a second-class citizen in the Nix world and a fair amount of stuff doesn't work properly (although I can't think of specific examples off hand). The Nix expression language seems unnecessarily unfamiliar to mainstream programming languages--I don't object to the functional nature, but I still spend quite a lot of time consciously thinking about syntax even though I've been using Nix on and off for ~7 years now (compared with e.g. typescript which I've barely touched and yet is trivial to read). Normally I don't complain about syntax, but you can do very little in the Nix world without reading and writing a bunch of nixlang and even if the other problems were resolved this alone would make it difficult to sell in most organizations since every developer would have to figure out how to work with it (package management is high-touch).

I'm a big believer in Nix's high-level approach to declarative systems, but the whole UX of Nix is so poor that foregoing declarative systems altogether is quite a lot less painful than using Nix in my experience. I'm rooting for it, but it really feels like Nix needs a product manager or something (no disrespect to the maintainers; these are difficult problems and I'm sure I wouldn't do a very good job). New users should beware.

[rgoulter]

> MacOS is still a second-class citizen in the Nix world and a fair amount of stuff doesn't work properly

In my experience:

With fewer nix users on macOS, it's more likely you'll run into software which isn't in the binary cache, & so will compile from source. (brew also does this).

With fewer nix users on macOS, it's may take longer for packages broken on macOS to be fixed.

It's a bit more of a hurdle to use .app programs out-of-the-box compared to brew, due to the symlinking.

[winterqt]

> With fewer nix users on macOS, it's more likely you'll run into software which isn't in the binary cache, & so will compile from source.

This isn't necessarily true, unless the package happened to fail to build on Hydra, or it just hasn't been built yet. (Every package is built for every platform that has builders in Hydra, it's not a matter of maintenance unless it just doesn't build.)

Does brew do this differently? I thought they also automatically compile every package.

[pxc]

.app programs which require Xcode to build weren't in the binary caches altogether, last I checked. Stuff with proprietary software in its build toolchain doesn't get built on Hydra.

I just use brew for .apps (and only for .apps) when I'm on macOS.

[JamesSwift]

Yep, I use Brew with a Brewfile to handle most casks. A select few I've manually created derivations for. This seems to be the path of much less resistance.

[SuperSandro2000]

> MacOS is still a second-class citizen in the Nix world and a fair amount of stuff doesn't work properly

and that will stay this way if Apple continues to make major and breaking changes with every update and changing MacOS more and more away from a BSD system and locking it further down.

[pxc]

I feel like Nix is worth it for me at this point, but I've definitely been through some of the pain described. This is a tough critique to hear for anyone who loves the project but I agree with the core of it (except the syntax issue).

Worth reading for Nix people and prospective Nix users alike, imo.

[throwaway894345]

Yeah, I don't want to rain on a parade; I think about it as opportunity for people who care about the project to rally around. I know plenty of people care about the user experience, but the current efforts seem kind of superficial and limited. It kind of feels like efforts are geared toward making Nix slightly better for its current user-base: individual, super-technical users who are really excited about package management and functional purity. Sadly, this misses out on Nix as a package manager for larger organizations (packaging their own software as well as configuring their hosts) as well as individual users who want the benefits of declarative systems but who don't want to learn a ton about package management, functional programming, Nix minutia, etc.

IMHO, it seems like there should be a UX working group that starts with broad scenarios and personas and develops a vision of what tooling should look like and works from there, rather than haphazard, incremental improvements on the current state of Nix tooling/workflows/etc. It could be interesting to look at how the Rust project makes big ambitious changes (they seem to do a really good job from my vantage point). Again, this is my view from afar as someone who has never run a big open source project and knows relatively little about package management (though thanks to Nix, much more than I ever wanted to know!).