> Plans include a gradual, piecewise introduction of the memory-safe Rust programming language
Oh cool, I had "rewrite in Rust" on my bingo card.
Anyway this doesn't seem to be much more than a %s/nix/lix/g so far. I'm all for the right to rage-fork something, but you should be clear that it's not a new project.
Well, they do say it's a fork in the About and FAQ pages. I'm guessing the front page's aim is to be broader, more newbie-friendly, more forward-looking, etc.
> Oh cool, I had "rewrite in Rust" on my bingo card
You may also be curious about tvix, which is a greenfield version in Rust, not a fork (but still pretty feature-incomplete, iiuc).
Ya, the best case here is that we end up with another implementation with its own benefits. I think that the existence of Guix and tvix (and others?) is beneficial, and the overarching idea of Nix is too big and useful to silo into just one project with one direction in mind.
Guix is cool, and I like Lisps, but it has very different goals, unfortunately. Culturally, it's quite hostile to any implementation on non-Linux platforms, and I use nix-darwin.
I agree the ideas behind nix should spread to how we build software in general.
Funny you should mention that. I've been trying to use it for a while, but the link on the Guix website to get a Hurd-based VM image is broken and I haven't been able to generate it myself.
Both this fork (Lix) and the other one (Aux - https://news.ycombinator.com/item?id=40200343) appeared in the context of the recent Nix drama, related submissions on which are presented below:
The NixOS community is currently discussing how to appoint a constitutional assembly within 2 weeks (that assembly will decide how to do community governance for the project). The discussions happen on Zulip: https://nixpkgs.zulipchat.com/ - and you can request an invite if you've contributed before.
Notable threads, which may be relevant to explain why these forks were created include:
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?
> 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/) which vents concerns over governance, community moderation, and involvement with Anduril.
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.
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.
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.
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.
> 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.
> No, but it does define how (and where) I will write that code.
I don't follow your rationale here.
e.g. many people write packages for their own "nix user repository". https://github.com/nix-community/NUR or there are examples of fairly sophisticated programs which declare packages outside of nixpkgs, such as helix or llamacpp.
> yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present
In a programming language, a function can be called with different arguments.
With Nix, since the packages are the result of functions, you can use these package definitions with whatever incompatibilities you like. -- I'm not sure what use case you're thinking of that Nix can't handle.
Nix can handle it, but can the user? That's my question. It took a while for me to understand the basic organization of nixpkgs well enough to do things like reconfigure a package properly for another package. Documentation-wise, the big picture isn't well-explained and, like I said, there is no official documentation recommending the use of a GUI tool to help. I see that there are tools available, but very little uptake of them in terms of documentation.
I am not sophisticated enough in Nix to say what a good roadmap would be. But I feel that if I were sophisticated enough I would be trapped in the mindset and not able to see how it could be made easier to comprehend for new users and tools. But who knows? As of now it's a very interesting puzzle and, while I take a lot longer to accomplish what I can do elsewhere, I enjoy the little aha moments along the way.
In this recent post discussing efforts which have been made to improve documentation, the author reckons that one of the reasons Nixpkgs is difficult to understand is that Nix's powerful expressiveness allowed different people to take different approaches to solve similar problems. (As opposed to, having to rely on a common solution).
IMO.. difficulties with Nix fall into three broad categories: with Nix's idiosyncrasies, with the Nixpkgs codebase, or with the software you're trying to get Nix to run.
On most OSs, you might not need to have a deep understanding of what's going on in order to fix a problem. With Nix (& NixOS), running into problems probably requires a decent grasp of what you're doing, as well as what Nix is doing, and maybe how the Nixpkgs code is doing it.
> the use of a GUI tool to help
I think between "easy/hard to understand" and "easy/hard to model with a GUI", GUI helps a lot with things that are easy, but not so much with things that are difficult.
e.g. with VSCode, you can get a GUI to help you set options. Emacs also has a GUI to help you customize options; but you don't get a GUI that helps you write elisp.
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.
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.
Initially I was like, "Oh cool, a new layer on top of Nix to make it more accessible!" And then read on to see it's basically just the NixCpp fork from save-nix-together now with Meson. I guess gradually moving to Rust is a cool idea, but there also exists tvix in that space with a greenfield version in Rust.
"Right to sponsor a project and get it to advertise your company" does not exist in any FOSS license that I know of. There's pretty much nobody complaining about Anduril using Nix, or even contributing to Nix. Many contributors have placed their ethical line at "accepting money from Anduril in exchange for services at official project events".
It's not helpful to misrepresent these things to try and simplify a complicated situation.
I don't think it was ever the issue itself that Anduril was sponsoring a conference. That should be a somewhat neutral issue anyway, any organization should determine what sponsors they want.
Of course there is a sizable group of people who view all MIC companies as furthering war, which had objected to the sponsorship on moral grounds. But Anduril never was the only issue.
Can we please, for the love of Flying Spaghetti Monsters, stop calling everything
new "modern" as if that word adds something to the quality of the product...
So... just by calendar time, no, nix probably isn't "modern". Though I do agree that calling a new thing modern isn't the most useful description; much better to say how it's better than the thing that came before it. The steel man is probably that "modern" is shorthand for "the underlying ecosystem/tools have shifted and the old thing suffers for not being able to adopt better ways of doing things, and this new thing will therefore be easier to work on / more robust / more feature-rich / less buggy / etc.", but I'd rather have that be articulated explicitly.
Then simply say, "Lix, a delicious implementation of the Nix package manager". The word modern is developers "game changer". It's so over used to the point of nauseating.
Doesn't that get the timeline backwards? I thought the RFC was opened in response to inaction on the part of switching to Meson, which had been informally agreed-on.
I don't have anything against people going their own way but having been on both ends of this kind of rumble in open source my resounding opinion is that you literally cannot please the aggrieved side.
It's a mixture of many things — some people are reasonable and just want sensible change, others are dangerous neurotics who need to go outside; both can end up, deliberately or not, using it as blackmail for control — but the moment the ball gets rolling it's pretty much impossible to stop.
I'd bail if a BDFL was an avowed Nazi but the bar for some just seems to be ridiculously low to the point where it's hard to imagine any (offline) social aptitude.
I'm not sure what gave me the impression but even from skimming the nix discourse the community's emergent personality did seem a bit snowflake-ish.
I've heard people make a kind of reverse-conway argument about Rust attracting (auth-) leftists, perhaps for another time...
Funny how it probably differs per ~5 years who is the most famous BDFL. I'd have gone for Linus Torvalds as the most famous, or maybe Guido van Rossum.
This self-labeling definitely adds to a… picture I have of the guy, from other practices (like extensive personality testing of job applicants, unusual questions about background)
Oh cool, I had "rewrite in Rust" on my bingo card.
Anyway this doesn't seem to be much more than a %s/nix/lix/g so far. I'm all for the right to rage-fork something, but you should be clear that it's not a new project.
https://git.lix.systems/lix-project/lix/commits/branch/main
You can see one of their most recent contributors is Eelco Dolstra.