Live data from Hacker News

How Nix and NixOS get so close to perfect

christine.website

121–130 of 183 posts

Re: How Nix and NixOS get so close to perfect

#121
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 “…

If they picked javascript I'm sure nix would be more popular, but also despised by the same crowd that currently loves it.

Re: How Nix and NixOS get so close to perfect

#122
post #18

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…

It can be done without the language itself having lazy evaluation. Each package can just have a function that outputs some data structure and the lazy evaluation happens on the package builder.

Re: How Nix and NixOS get so close to perfect

#123
post #61
post #42

Earlier quoted context omitted.

What a bad analogy. Betamax was superior to vhs.

Betamax was superior to VHS, but it lost to VHS because you could record an entire football game on one VHS tape. GNU is football games in this metaphor, because the GNU+obsession that Guix has is what is really holding it back from wider success. Nix/NixOS is kinda shit, but at least you can easily run closed source software on it.

You can easily add channels in Guix to install nonfree software, e.g. Steam. I don't even have to do a Nix-style `allowUnfree`.

Re: How Nix and NixOS get so close to perfect

#124
post #93
post #88

Earlier quoted context omitted.

It's crate2nix: https://github.com/kolloch/crate2nix

No, unless something significantly changed there. There's another project like naersk which doesn't need to generate a "Cargo.nix" file.

Maybe cargo2nix? https://github.com/cargo2nix/cargo2nix

Re: How Nix and NixOS get so close to perfect

#125

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.

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.

You can. So long as the impurity is scoped to be local within a package. And the system itself only reads the output of your language to configure something. Example:

  def packageInstaller(pkgs: Pkg) -> Derivation:
      x = {
          req: [pkgs.a, pkgs.b]
          build: 
          ...
      }

      x[req].append(pkgs.c)
      return buildDerivation(x)
packageInstaller outputs a single package description, but you can also create something similar that easily outputs an entire configuration for the OS. You just need to keep mutation scoped within the language. The configuration that is outputted is immutable and whatever thing that's processing that configuration is not within user control.

Keep in mind that mutability and immutability share a certain isomorphism. Within the nix expression language you often do something similar to mutation just as any other functional language. For example:

    listVersion3 = listVersion1 ++ AdditionalStuff
It's just that in functional languages you're forced to keep versions of each mutation.

Re: How Nix and NixOS get so close to perfect

#126

Earlier quoted context omitted.

Because industry makes good decisions? Decisions like adopting python, dooming a large part of the world software to be bug ridden slow messes. Or to elevate CUDA to the facto machine learning backend? Besides it's not clear that Haskell isn't adopted by industry due to the syntax.

> Because industry makes good decisions? That's irrelevant - if you want uptake, you need to support what user's want. It's been clear for at least a decade now that programmers don't want Haskell syntax. Whether it's a good syntax or not is irrelevant.

> That's irrelevant - if you want uptake

Haskell's slogan is "avoid success at all costs". Haskell isn't aiming for mass adoption. It wants to be a language for researching functional programming, it just so happens it's a useful language, and people write real software with it too.

From https://haskell.foundation/whitepaper/ > Haskell's slogan of "avoid success at all costs" was a clever and cheeky way of saying that innovation and research in programming languages, especially in functional programming, needed some insulation to succeed

Nix doesn't have such a slogan as far as I know. It, however, started as a thesis to try and research and innovate new ideas. https://edolstra.github.io/pubs/phd-thesis.pdf The Purely Functional Software Deployment Model.

Twenty years later, it's been rather successful as a research project, one of the most active repos on GitHub. It has gained a lot of usage and support without trying to be successful, popular or market itself.

The Nix language has helped it achieve what it set out to achieve. It's appealing to people who are interested in purely functional software. If that doesn't appeal to Javascript / PHP devs that's ok as it isn't trying to appeal to them.

The Nix expression language is small and pretty simple; everything is an expression.

The difficult bit is there are no javadoc/jsdoc/pydoc type docs beyond https://nixos.org/manual/nix/stable/expressions/builtins.htm... where you can go search easily. You have to go through the source code to find functions and see how they work. Also, you have to accept Nix is a ML style language, not a C style language. It's different to what you may know, but that isn't a fault of the language if someone only knows C style languages. The language is as it needed to be like that to achieve the design it wanted. Personally, I hate using Ansible firstly because of YAML. Secondly, Ansible is a task runner, often feeling like you are over abusing Ansible for things that are not a natural fit, and the debug headache dealing with determinism by convention only.

I think it comes down to Nix isn't for you. That's ok.

Re: How Nix and NixOS get so close to perfect

#127

Earlier quoted context omitted.

Because industry makes good decisions? Decisions like adopting python, dooming a large part of the world software to be bug ridden slow messes. Or to elevate CUDA to the facto machine learning backend? Besides it's not clear that Haskell isn't adopted by industry due to the syntax.

> Because industry makes good decisions? That's irrelevant - if you want uptake, you need to support what user's want. It's been clear for at least a decade now that programmers don't want Haskell syntax. Whether it's a good syntax or not is irrelevant.

Heh, there's a project I'm trying to get into and it's written in Haskell, I gotta learn it... if possible I'm probably going to port it to something else.

Re: How Nix and NixOS get so close to perfect

#128
post #106

Earlier quoted context omitted.

>has clearly been unacceptable to the industry for a long time. What?? Galois, Facebook, IBM, Twitter, AT&T, Bank of America, Barclays Capital, NVIDIA, Microsoft and GitHub use Haskell. https://wiki.haskell.org/Haskell_in_industry

> What?? Galois, Facebook, IBM, Twitter, AT&T, Bank of America, Barclays Capital, NVIDIA, Microsoft and GitHub use Haskell. So? The usage of Haskell within the entire industry is so small it's not even a rounding error. It's hard to make the argument that the industry has accepted it when the industry usage is too tiny to even measure properly.

Please define "the industry" and explain what credentials you have to know what "they" want.

Re: How Nix and NixOS get so close to perfect

#129
post #107

Earlier quoted context omitted.

>if you want uptake, you need to support what user's want Before the iPhone no one knew they wanted a good camera and "apps" on their phone. See the important point here -> "knew they wanted"

> >if you want uptake, you need to support what user's want > Before the iPhone no one knew they wanted a good camera and "apps" on their phone. > See the important point here -> "knew they wanted" Haskell has been around now for something like 25 years. You'd have a point if the iPhone was unpopular for 25 years before users finally decided to like it. It wasn't. Users saw the iPhone and wanted it the minute they sa…

Say it with me: right tool for the right job. Not every language should try to solve every problem. And not every problem is nicely solvable in every language. By your definitions any language other than what, C and js is "unpopular" and "Rejected by the industry" ?

Re: How Nix and NixOS get so close to perfect

#130
post #28

Two years ago I tried to set up my home-webserver with nixOS. I failed miserably. The post hits the nail on the head: The documentation is horrible, and barely differentiates between the language, the package manager and the OS itself. I really like the idea behind nix; maybe something with better execution comes up one day :)

I’m holding out for this - Nix is the only tech I veto in startups I work at nowadays because I’ve never seen it go well beyond small dev scripts, and time spent on Nix is time taken from the product/project.
Post reply on HN