Show HN: Brioche – A new Nix-like package manager

Very smart

Honestly, I think the "stringly-typed targets" thing isn't too bad, having used Buck2 quite a bit, and being a Nix user for 10+ years. If anything, it's a small price to pay for some of the other smart things you get in return, like the far more fine-grained action graph and the tooling around BUILD files like querying. One weird benefit of that stringly-typed bit is that the BUILD files you have don't even have to meaningfully evaluate or even parse correctly, so you can still build other subsets of the tree even when things are broken; at ridiculous-scale it's nearly impossible to guarantee that, and it's something Nix does worse IMO since evaluation of the full nixpkgs tree is slow as hell in my experience but a requirement because a single eval error in the tree stops you dead in your tracks.

Also, no matter how much I might not like it as a language nerd, I think Starlark is simply far more "familiar" for your-average-bear than the Nix language is, which matters quite a bit? It might be more complex in some dimension, but the problem space is fundamentally complex I think. So other factors like how approachable the language is matters. (And at least in Buck2, you can use MyPy style typing annotations, thank God.)

> I've seen a lot of complaints about the language, but a lot of praise and love of the idea

I think when people say they like the idea of nix, they're referring to how it builds packages from programmatic package formulae into an isolated store (so e.g. you can easily have different programs running against different versions of dependencies), and the use cases this allows for. -- With an expressive language for describing packaging, you get stuff like declarative developer environments, or even declared Linux configuration with quick/easy rollback.

I think complaints about the language are partly from Nix being unusual enough that it takes time to get an intuition for the basics of how to write anything in it, but largely from the Nixpkgs (the large package repository the Nix package manager uses) being a large codebase, which grew organically with many contributors, with many similar-but-different solutions to problems, and sometimes the codebase is a bit too clever.

Reminds me of this quote from Douglas Adams:

  I've come up with a set of rules that describe our reactions to technologies:
    1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
    2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
    3. Anything invented after you're thirty-five is against the natural order of things.

It's been used to criticize anyone who rejects new technology, but it's just a funny quote that has some truth to it.

Here's what's been key for me:

Absolutely separate -- in your mind -- NixOS from Nix.

The latter I've seen be a very useful tool that does what people here talk about: cleans up dependency and build and installation management in a reasonably nice way.

The former is a religion/world-view that requires a complete mindset change, accepting a whole dogma, and differs entirely from how you're used to using Linux. I gave up and switched back to Debian after I couldn't get a decent answer on how to set it up easily with my github keys to easily, y'know, check projects out. The mental gymnastics required wer silly.

Nix the language seems obscure at first but it's not so bad after a while. It's sort of got a bit of syntax tossed in from the ML-ish programming languages so there's some familiarity there, for me, maybe.

Where it falls down is like anything else like this: it basically requires that all the things you dep on also adhere to this philosophy and have nix setups already or you'll be in a world of pain rolling your own. I gave up on converting our $work stuff when it became clear that the versions of flatbuffers and a few other deps we depend on just weren't out there in the nix ecosystem and I wasn't going to volunteer to make them.

Anyways, I've seen it be very useful. A former employer used it to set up their whole Julia environment such that custom patches and configuration would all be nicely applied. And this was for both developer workstations and CI and production environments. It's a nice step below docker for doing that kind of thing, and is far less intrusive than docker in many ways.