4 ms·

What's the goal here? As a Nix[OS] user for a couple years now, the underlying Nix impl is not really on my radar for personal problems i have with Nix. It's en

What's the goal here? As a Nix[OS] user for a couple years now, the underlying Nix impl is not really on my radar for personal problems i have with Nix. It's entirely about the language and (lack of) language-tooling. I write typed systems on purpose during my day/hobby programming, and dynamic untyped experiences are just no fun for me personally. Nickel is far more interesting to me on my checklist of UX issues. Kinda surprises me to see larger rewrites of various Nix systems that i've not had issue with. Am i missing something?

constantcrying 2y ago
>Am i missing something? The issue isn't really technical. It is a conflict over governance of nix, caused by multiple factors among them involvement of US military industry companies sponsoring conferences and a general dissatisfaction with leadership.
rgoulter 2y ago
> What's the goal here? ... Am i missing something? Forks tend to be for social reasons, rather than technical. e.g. NeoVim was forked out of frustration relating to a complicated changeset being rejected. Or OpenTofu over licensing issues. There's an open letter (https://save-nix-together.org/ https://save-nix-together.org/) which vents concerns over governance, community moderation, and involvement with Anduril.
projektfu 2y ago
I agree, as a new user I think Nix(os/pkgs)'s deficiencies are: 1. Documentation doesn't really explain how NixPkgs works and thus there is a lot of magic that is unintuitive for a new user. 2. The Nix language has a number of annoying gotchas. I always go through several rounds of syntax errors before several rounds of name errors before code can run. 3. Whence this definition? NixPkgs' extreme inversion of control approach makes it hard to guess by looking at code, and I haven't found how to set up good tooling. 4. Clickability. Sometimes you just want an official way to turn things on and off or choose defaults and there is no officially-supported GUI helper. This makes it hard to expect that people will start to use Nix who aren't basically functional programmers already. I don't think I could convince people to use it. 5. Efficiency. Long-ish build times for simple changes, too much memory use to run nixos-rebuild on a small computer.
- thomastjeffery 2y ago
  I think you touched on it with #3, but here is my biggest issue with Nix: nixpkgs It's a monolithic source tree full of disorganized interdependent "derivations". It's nigh-impossible to find your bearings, and that's before you even think about the bazillion git branches and GitHub PRs. I started this GitHub issue about 4 years ago: https://github.com/NixOS/nixpkgs/issues/93327 https://github.com/NixOS/nixpkgs/issues/93327 The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. I came to NixOS hoping for a package manager; but what I got is something else entirely. I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other. The nix language isn't the problem. The problem is the impenetrable novel that was written in it.
  - rgoulter 2y ago
    This is partly fair and partly unfair. I think it's reasonable to say that the nixpkgs codebase is a behemoth that can be quite difficult to understand. I think "nix and multiple versions of a package" is more nuanced. In that thread, several of the replies are saying "just use ...". As in, it's possible to vary the version of a package built. But, nixpkgs itself only has multiple versions of some package when that package is very popular (e.g. python, nodejs). > The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. ... I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other. Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository. Taking one large codebase and splitting it up into many codebases doesn't necessarily simplify things overall.
    - thomastjeffery 2y ago
      > Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository. No, but it does define how (and where) I will write that code. It's not uncommon for a package to need complex dependencies like udev. It's definitely necessary for nixpkgs to have opinionated decisions about how dependencies are structured, and what options/defaults are available and where. The problem isn't the quality of nixpkgs, or with any of its design decisions. The problem is that those design decisions are centralized and interdependent. That's the core issue that lead nixpkgs to be so poorly documented. It's the core issue that makes it incredibly challenging to create a sensible UI/UX for Nix and NixOS. There are definitely benefits to a monolithic source tree. You can guarantee compatibility. You can have a clear place for communication about breaking changes and security updates. The thing is: you can get all of this without a monolithic source tree. Debian has been doing it for 30 years now. If anything, Nix should be able to do it better! If the goal is to have a diverse set of package repositories, what better way to deliver them than a purely-functional declarative package manager? Nix is the one package manager that can handle totally incompatible packages, breaking changes, etc. all without breaking a sweat; yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present. I see it as a missed opportunity.
tempaccount420 2y ago
It's easier to find motivated Open Source contributors to a Rust project than a C++ project. It's also easier to integrate with a Rust project, reusing parts of it to make language tooling.

constantcrying 2y ago

>Am i missing something? The issue isn't really technical. It is a conflict over governance of nix, caused by multiple factors among them involvement of US military industry companies sponsoring conferences and a general dissatisfaction with leadership.

rgoulter 2y ago

> What's the goal here? ... Am i missing something? Forks tend to be for social reasons, rather than technical. e.g. NeoVim was forked out of frustration relating to a complicated changeset being rejected. Or OpenTofu over licensing issues. There's an open letter (https://save-nix-together.org/ https://save-nix-together.org/) which vents concerns over governance, community moderation, and involvement with Anduril.

projektfu 2y ago

I agree, as a new user I think Nix(os/pkgs)'s deficiencies are: 1. Documentation doesn't really explain how NixPkgs works and thus there is a lot of magic that is unintuitive for a new user. 2. The Nix language has a number of annoying gotchas. I always go through several rounds of syntax errors before several rounds of name errors before code can run. 3. Whence this definition? NixPkgs' extreme inversion of control approach makes it hard to guess by looking at code, and I haven't found how to set up good tooling. 4. Clickability. Sometimes you just want an official way to turn things on and off or choose defaults and there is no officially-supported GUI helper. This makes it hard to expect that people will start to use Nix who aren't basically functional programmers already. I don't think I could convince people to use it. 5. Efficiency. Long-ish build times for simple changes, too much memory use to run nixos-rebuild on a small computer.

thomastjeffery 2y ago
I think you touched on it with #3, but here is my biggest issue with Nix: nixpkgs It's a monolithic source tree full of disorganized interdependent "derivations". It's nigh-impossible to find your bearings, and that's before you even think about the bazillion git branches and GitHub PRs. I started this GitHub issue about 4 years ago: https://github.com/NixOS/nixpkgs/issues/93327 https://github.com/NixOS/nixpkgs/issues/93327 The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. I came to NixOS hoping for a package manager; but what I got is something else entirely. I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other. The nix language isn't the problem. The problem is the impenetrable novel that was written in it.
- rgoulter 2y ago
  This is partly fair and partly unfair. I think it's reasonable to say that the nixpkgs codebase is a behemoth that can be quite difficult to understand. I think "nix and multiple versions of a package" is more nuanced. In that thread, several of the replies are saying "just use ...". As in, it's possible to vary the version of a package built. But, nixpkgs itself only has multiple versions of some package when that package is very popular (e.g. python, nodejs). > The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. ... I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other. Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository. Taking one large codebase and splitting it up into many codebases doesn't necessarily simplify things overall.
  - thomastjeffery 2y ago
    > Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository. No, but it does define how (and where) I will write that code. It's not uncommon for a package to need complex dependencies like udev. It's definitely necessary for nixpkgs to have opinionated decisions about how dependencies are structured, and what options/defaults are available and where. The problem isn't the quality of nixpkgs, or with any of its design decisions. The problem is that those design decisions are centralized and interdependent. That's the core issue that lead nixpkgs to be so poorly documented. It's the core issue that makes it incredibly challenging to create a sensible UI/UX for Nix and NixOS. There are definitely benefits to a monolithic source tree. You can guarantee compatibility. You can have a clear place for communication about breaking changes and security updates. The thing is: you can get all of this without a monolithic source tree. Debian has been doing it for 30 years now. If anything, Nix should be able to do it better! If the goal is to have a diverse set of package repositories, what better way to deliver them than a purely-functional declarative package manager? Nix is the one package manager that can handle totally incompatible packages, breaking changes, etc. all without breaking a sweat; yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present. I see it as a missed opportunity.

tempaccount420 2y ago

It's easier to find motivated Open Source contributors to a Rust project than a C++ project. It's also easier to integrate with a Rust project, reusing parts of it to make language tooling.