The Nix NGI Team: Advancing Open Source with Nix | Hacker News Reader

The Nix NGI Team: Advancing Open Source with Nix

discourse.nixos.org

78 pointsidabzo29 comments

It's good to see EU funding for open source, and for getting software easy to build, as Nix does.

Bravo to the EU, NLNet and the NixOS contributors making this possible!

The Nix@NGI team has one clear mission: to make open source software easier to run—now and in the future.

Through the NixOS Foundation’s collaboration with NGI Zero, we’re tackling over 1,200 NLnet-funded software projects, packaging them for Nix and enhancing their discoverability. Our work focuses on building development environments, libraries, services, and more, while also improving tools and processes for the entire Nix community.

This is very cool. Can you disclose how much funding NixOS is getting via NGI Zero?

Does anyone know: is there a simplified nix language initiative out there? I feel like the main blocker for nix adoption is the language itself.

Guix is an alternative implementation - based on the same general design principles as Nix. It uses Guile scheme as the language, which is at least a more conventional programming language.

Guix not supporting systemd is the biggest reason I have for not giving it a go.

Linux distros work well without systemd. In fact, as someone who at one point worked very heavily with it, systemd being absent from a system almost guarantees that it will work better.

Gentoo has openrc, which is a billion times less insane.

This is just plain misinformation, since systemd "won" all packages targets systemd and it's quirks to make all work together.

It doesn't matter if you think systemd is good or bad, a generic system with systemd works better.

If you're a fan of monocultures, then all of this is irrelevant since you're using Ubuntu and the quirks of nix/nixos/guix don't matter.

I use NixOS on all my machines. NixOS relies heavily on systemd by design. NixOS would be a lot harder to implement without systemd. With Nix(OS) we can just dump systemd unit files on disk, reload and move on.

There are other declarative init systems that could replace systemd, but what's the point when systemd does everything?

> I use NixOS on all my machines. NixOS relies heavily on systemd by design. NixOS would be a lot harder to implement without systemd. With Nix(OS) we can just dump systemd unit files on disk, reload and move on.

I think guix, nix-darwin, and nixbsd all prove that you can in fact implement such a system just fine without needing systemd.

> There are other declarative init systems that could replace systemd, but what's the point when systemd does everything?

Because systemd doesn't do everything, and depending on it artificially limits what we can do. See guix running on hurd, nix-darwin running on darwin, and nixbsd running on freebsd; systemd explicitly has no interest in supporting anything but Linux.

Gentoo with openrc has less problems with the init system than Arch has, at least in my experience.

That aside, systemd is a genuinely terrible software project and a genuinely terrible init system.

Just FYI, before my experience of 5 days a week dealing with systemd, I thought people who disliked it were just exaggerating or wanting to be "different". I assumed most hate it was getting was undeserved. My professional experience made it absolutely clear to me that every piece of hate it is getting is well deserved. It is bad software all around, terrible design decisions, completely unpredictable, hard to debug and all around very poorly integrated into the rest of the system.

Enlighten me with the bad design desicions, I use systemd extensively and there are few design decisions I dislike. Some UX could be better but overall I wholeheartedly think systemd is good software.

There's Lix, although I'm not clear on if it's about changes to the language or if it's entirely focused on improving the tooling.

https://lix.systems/

There are a whole lot of attempts of "Our own Nix, with blackjack and hookers" and so far none of them have any traction. (Not counting Guix here.)

I don't think any of them are trying to make huge changes to the language itself, considering that an inability to use Nix packages would be a deal breaker for basically everyone.

Configuration is a hard problem as evidenced by all continuous reinvention of configuration formats (YAML TOML XML etc). They're all "simplified" and that's why they fail at more advanced use cases. Once you get over a few syntax quirks and the tendency of advanced users to use a bunch of syntax shortcuts, which are confusing to new users, Nix is actually a very terse but conceptually quite simple functional language which has exactly the right amount of complexity to map to its problem space.

Nix the language has issues for sure (error messages for starters), but "complexity" isn't really one of them IMO. It's quite a small and simple language.

The complexity comes in with the ecosystem and nix-the-build-system, each of which has a dozen different ways to do any given thing, all of which are in active use simultaneously. Some are pretty baffling, like nixpkgs' dual role as both the main package repository and the (almost entirely undocumented) de facto standard library

Exactly this. One of the first things I tell people struggling with nix is that nix is simple and almost all of the complexity lives in nixpkgs. Knowing where to look for help (is this a nix, flakes, NixOS, or nixpkgs thing?) is one of the hardest problems for beginners.

Nixpkgs specifically needs to be entirely rethought. It has become too large and complex to manage both technically and politically with the number of contributors. Separating out the lib, stdenv/tooling, and package definitions would be a good start.

Nix is actually really simple (basically json with functions) and can be learned in under an hour, see https://nixcloud.io/tour/?id=introduction/nix

IMO the nix language is excellent as templating language, I'd happily use it instead of jinja2 for generating html at a daily job, maybe this will be possible at some point.

The language is alright, the documentation and rate at which things change is the issue.

You wanted to do something and found a page about how to do it? Cool, good chance it won't work anymore cause it changed. If you do get an error from nixos-rebuild because of your nix files, the error report will probably not be useful either.

The Nix language is possibly the simplest programming language known to man. Try to "simplify" it further and you'll get raw lambda calculus.

In short, no, the language is not the source of difficulty.

I think the main problem with writing nix configurations is the lack of a good LSP. If I hand autocomplete for options, and some kind of global search (e.g. everything related to `postgres`), it would be much easier to use it.

I recommend getfleek.dev for $HOME and https://www.jetify.com/devbox for dev environments that leverage nix using simple JSON.

The language is really simple, actually. People who complain about Nix language being hard actually complains about things implemented in Nix being hard.

Nix is essentially jsonnet, which you'd argue is simple... Because your first interaction with it isn't implementing an operating system.

I'm a bit disappointed that nobody really answered your question. I admit that maybe asking for Nix to be simpler is a bit loaded, because I think people are right in that Nix is "simple", but it's definitely not simple to use in practice.

Several people have worked on offshoots of Nix and the Nix language that try to address this in different ways. For example, there is Nickel: https://github.com/tweag/nickel

I think the Nix language is OK for what it is: lazy evaluation and functional purity is a good fit for what Nix aims to do. That said... I definitely feel like functionally-pure programming languages have trouble when it comes to trying to write maintainable code. I'm sure that statement would anger some, but it is my personal belief trying to use functional programming languages as a life long imperative programmer: the advantages of functional purity are pretty obvious, but writing code that you can't make sense of later is so much easier for me in functional languages. They're so powerful and elegant that writing nearly indecipherable things feels very tempting at times.

So, I'd be interested in seeing someone attempt a Nix-like ecosystem built around something else. If Bazel can do "hermetic-ish" with Starlark, I reckon you could pull off something like Nix with it, too.

Maybe they should fix existing packages first. cough https://archive.fosdem.org/2024/schedule/event/fosdem-2024-1...

Reply on news.ycombinator.com