Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Nix and NixOS get so close to perfect

christine.website

Post reply on HN
Print view View original

11–20 of 183 posts

Re: How Nix and NixOS get so close to perfect

#11

Post by KronisLV »

mananaysiempre wrote: post #6
atoav wrote: post #3

As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…

> Using Haskell as a base for the syntax I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: - Kind of like Lisp (parens everywhere, painful with pervasive currying); - Kind of like ML (var and fun everywhere); - Kind of like Haskell. Nix is chooses the last of those, and it does not have most of Haskell’s funkiness: no “…

> I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities:

How so? Where's the Java/Python-like languages in this consideration, why wouldn't those work? Or something more like Ansible?

I'm pretty sure that you can express the same concepts for the most part in something imperative as well.

Re: How Nix and NixOS get so close to perfect

#12

Post by zoul »

Athas wrote: post #4
dmitriid wrote: post #2

Somehow 60% or more of the presentation is spent on what is charitably called "papercuts": bad tooling, bad documentation. It's not "getting so close to perfect". A jet-powered cart (from the comic in the presentation) is not "close to perfect" by any imaginable criteria. Well, unless your idea of perfect is "a jet-powered cart".

I feel differently: when proponents of a thing are open about its flaws, and those flaws are not in the fundamental ideas or principles of that thing, then it makes me more convinced that perhaps the thing does have merit. (Although I can buy the argument that it's not close to "perfect", mostly because I have no idea what perfect package management would look like.)

Maybe having terrible UX is starting to look like a fundamental flaw here? I know that UX sounds like something that should be “polishable”, but at this moment I have been hearing for years about Nix being great in principle but not that great in everyday practice. (Cf. Linux on desktop…)

Re: How Nix and NixOS get so close to perfect

#13

Post by colordrops »

KronisLV wrote: post #11
mananaysiempre wrote: post #6

Earlier quoted context omitted.

> Using Haskell as a base for the syntax I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: - Kind of like Lisp (parens everywhere, painful with pervasive currying); - Kind of like ML (var and fun everywhere); - Kind of like Haskell. Nix is chooses the last of those, and it does not have most of Haskell’s funkiness: no “…

> I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: How so? Where's the Java/Python-like languages in this consideration, why wouldn't those work? Or something more like Ansible? I'm pretty sure that you can express the same concepts for the most part in something imperative as well.

I don't see how you could maintain purity and reproduceability with something imperative. I used ansible for a while and it was a mess that broke half the time and was difficult to maintain.

Re: How Nix and NixOS get so close to perfect

#14

Post by colordrops »

goodpoint wrote: post #9
atoav wrote: post #3

As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…

Guix seems to be a better bet.

Maybe a better design. Bet? Not so sure. Guix is Betamax to Nix's VHS.

Re: How Nix and NixOS get so close to perfect

#15

Post by colordrops »

zoul wrote: post #12
Athas wrote: post #4

Earlier quoted context omitted.

I feel differently: when proponents of a thing are open about its flaws, and those flaws are not in the fundamental ideas or principles of that thing, then it makes me more convinced that perhaps the thing does have merit. (Although I can buy the argument that it's not close to "perfect", mostly because I have no idea what perfect package management would look like.)

Maybe having terrible UX is starting to look like a fundamental flaw here? I know that UX sounds like something that should be “polishable”, but at this moment I have been hearing for years about Nix being great in principle but not that great in everyday practice. (Cf. Linux on desktop…)

I'm not convinced that Nix isn't polishable. Because the language is declarative, and can be pure if using flakes, it could readily be extended with simple tooling and UI configuration that make it look and feel like other distros, with the more low level constructs still available to advanced users. It's still in a phase where most users are power enthusiasts, so polish hasn't been priority #1, but someone will come along and make a more friendly wrapper one day.

Re: How Nix and NixOS get so close to perfect

#18

Post by cwp »

KronisLV wrote: post #11
mananaysiempre wrote: post #6

Earlier quoted context omitted.

> Using Haskell as a base for the syntax I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: - Kind of like Lisp (parens everywhere, painful with pervasive currying); - Kind of like ML (var and fun everywhere); - Kind of like Haskell. Nix is chooses the last of those, and it does not have most of Haskell’s funkiness: no “…

> I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: How so? Where's the Java/Python-like languages in this consideration, why wouldn't those work? Or something more like Ansible? I'm pretty sure that you can express the same concepts for the most part in something imperative as well.

Yes and no. Yes, because Turing completeness. But no, because if you tried to do something like the Nix package manager with a language like Python or Java or even Scheme (yeah, I'm looking at you Guix), you'd end up with a worse system.

What's great about Nix the language is that its design matches beautifully with its purpose. Nixpkgs is a single giant program, the output of which is a set of 70,000 package definitions. Since Nix uses lazy evaluation, you can specify one of the attributes of that set, a single package, and the Nix interpreter will evaluate just that one package expression. Of course, if that package depends on other packages, those will get evaluated as well, because they're needed as inputs to the package you care about. So package dependencies emerge naturally as computational dependencies between function invocations. This is really powerful, and over the years, Nixpkgs has evolved more and more sophisticated ways of defining packages - package overrides, the overlay system, and most recently, flakes.

So yes, using an imperative language would technically be possible, but I doubt that you could use it to build the largest and freshest package repository with a fraction of the contributors that other packaging systems have.

Re: How Nix and NixOS get so close to perfect

#19

Post by microtonal »

k__ wrote: post #16

It's kinda ironic, the biggest innovation in package management and OS design is basically unusable for the average tech person. Compared to Nix, every other package manager is a security liability.

Compared to Nix, every other package manager is a security liability.

Nix is great, but I don't see much difference with respect to security. In fact, Nix encourages and flakes formalize pinning of nixpkgs versions. I am sure that there are a bazillion repositories/configurations out there that use a pinned nixpkgs version with known vulnerabilities in glibc, libxml, or whatever.

Besides that, packages in nixpkgs often have known vulnerabilities for months, because of a lack of volunteers to maintain all of nixpkgs.

I love Nix and the large amount of work that goes into nixpkgs. But let's avoid every Nix discussion becoming a 'Nix evangelism strike force' has landed kind of thing. Be honest about Nix' strengths and weaknesses.

Re: How Nix and NixOS get so close to perfect

#20

Post by emteycz »

cwp wrote: post #18
KronisLV wrote: post #11

Earlier quoted context omitted.

> I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: How so? Where's the Java/Python-like languages in this consideration, why wouldn't those work? Or something more like Ansible? I'm pretty sure that you can express the same concepts for the most part in something imperative as well.

Yes and no. Yes, because Turing completeness. But no, because if you tried to do something like the Nix package manager with a language like Python or Java or even Scheme (yeah, I'm looking at you Guix), you'd end up with a worse system. What's great about Nix the language is that its design matches beautifully with its purpose. Nixpkgs is a single giant program, the output of which is a set of 70,000 package definit…

Well said. Using imperative language would be possible but then it'd look like a bunch of function invocations, not like a class declaration. And people would be asking "this is crazy, why don't you create a DSL for this? My IDE can't ever understand this".
Post reply on HN