Live data from Hacker News

Nix: Taming Unix with Functional Programming

tweag.io

151–160 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#151
post #15

Earlier quoted context omitted.

I have tried Guix (as a package manager), and it seems much better documented. I also really like the fact that Guix uses a well-established, minimalistic, well-implemented, functional-preferred configuration language, which is Guile, the GNU implementation of Scheme, which is very much tailored to be extended with and embedded in other software, for example written in C. In part, my love comes from having had to use…

> minimalistic The Nix language is far more minimalistic than any Scheme. I have nothing against Scheme but let's be clear, Nix out-Schemes Scheme in this regard.

For somebody who knows Lisp and Scheme, it is however more than nice to already know the language and be able to just read the interface description.

To give an extreme example of the opposite direction (no, I do not want to bash Nix here), take CMake and its configuration language which has no real definition. It is just painful to use.

Re: Nix: Taming Unix with Functional Programming

#152

Earlier quoted context omitted.

I think nix probably needs a more beginner friendly documentation as well, by beginner friendly I mean Linux beginners. Beginners will not read through nix pills (assuming they can understand it) before trying nix, they will just give up. And there are a lot of Linux users who don't have much technical knowledge about how binaries are being linked, etc. I think the ecosystem is now mature enough for beginner users to…

Why is it necessary for Nix to be accessible to Linux beginners? Sure it’d be nice to have, all else being equal, but I don’t see how it helps advance the goals of the project for the people who are using it today.

Because why not? For things like installing (commonly used) packages, setup some services, I think Nix is simpler than things like Debian or Arch. You don't need to understand all the nitty-gritty to install a package. The problem is about the documentation, some information is old (nix-env for example which should be deprecated IMO), may need better discoverability (options that you don't know they even exists), and we should be able to just give some examples for users to modify instead of asking them to learn the whole language.

For advancing the goals of the project, I think increasing adaptation will be beneficial, for example to let more software provide a nix script for building, due to more users using it. And perhaps if more users are using it, more companies and universities will adapt it.

Re: Nix: Taming Unix with Functional Programming

#153

Earlier quoted context omitted.

Semver doesn't really apply here since nix always points at a specific version of each dependency. Multiple package versions are not visible to the same app. And you can include your own lockfile-like list. So in practice, it's not really a bigger problem for nix than for any other release. If you need to freeze versions for an app, you freeze them. If you don't or if you're packaging a library, you can (usually) rel…

The thing that you and sibling miss is that this only applies to the one direct dependency on a package, but not on dependencies required by that package. For that you have to work with any build and dependency resolution system that the package or its author uses, and you're up a creek without a paddle if the author doesn't care to help you debug your own system.

I'm not missing this. It's not a problem the way you describe it. With nix you generally choose between packaging with deps that are in the repo, or effectively provide your own list of vendored versions. Both cover all the deeper dependencies and you get the choice of integrating with the project's build system or ignoring it and providing your own lockfile equivalent. (the latter especially if the build does something really weird)

Even if authors are not responsive, nix maintainers provide the required patches or disable the broken functionality. So no, things are mostly ok.

Re: Nix: Taming Unix with Functional Programming

#154
post #21

Earlier quoted context omitted.

> Nix needs a new porcelain interface for it's CLIs. It already has one with the 'nix' command, it just needs to be manually enabled under 'experimental-features', but once done there is basically no reason to ever touch any of the old commands.

Yup. I started with Nix a little over a year ago on Nix 2.3, and have only ever used flakes and the new CLI. It's complete from my point of view— the main issue is just that the pills and all the official documentation still refer to the old commands. I wish they'd flip it over to being the default and update the docs. I know that's not trivial, and it's hard when all the long-time community members have the legacy c…

I started with a single system on NixOS around February of this year. I just recently saw an example of `nix search` instead of `nix-env -qaP`. I haven't seen any documentation for all of this new stuff. Any place to go, or do we just have to go read the source code?

Re: Nix: Taming Unix with Functional Programming

#155

Earlier quoted context omitted.

That's fair. I blamed immutability when I should have blamed the implementation. Thanks for helping me realize my mistake. :) Availability of packages is what makes or breaks a distribution, though. If I can't (easily) install the software I need to do my job, I choose a distribution that can. My home Ubuntu server isn't bringing me joy, so maybe now's a good time to give Nix another shot. Fingers crossed for Nvidia…

In my experience the Nvidia driver support has been pretty painless (once you figure out the correct settings in configuration.nix of course), and the availability of packages is by far the best of any linux distro I've used.

I've been working on a project that uses Nix, and from an archlinux host with Nvidia hardware it has been very far from painless, with nixGL breaking every time Arch updates glibc

Re: Nix: Taming Unix with Functional Programming

#156
I have tried starting nix several times never got all things working. However, after being stuck in several dependency hells both in personal projects and at work, I knew I wanted what nix was proposing.

This last time I tried it actually clicked much better. I think what flakes has done is not just provided the technical solutions for why it was created, but it also made it much easier to understand a nix repo and to a newbie like me it almost seems like it results in cleaner code (I now much more often end up understanding what a nix file is doing). That together with the updated nix command in general makes it much more intuitive in most of the cases.

So I just wanted to say that to the nix team that your focus on UI is paying off for newbies like me.

Re: Nix: Taming Unix with Functional Programming

#157

I built my router and NAS from NixOS. It was a mostly pleasant experience. Being able to sit in an IDE on my laptop, and build up a server, incrementally pushing changes to it, with rollback if necessary, was great, and I wouldn't want to go back to anything else. I wrote about the router here. It's pretty heavy on router stuff, and my own thoughts though... https://www.jjpdev.com/posts/home-router-nixos/

Excellent read, thank you! Just in time, I have been eyeing one of those tinyminimicro pcs to replace OpenWRT with Nix. Could you share more details on push_to_router.sh? Is it a wrapper around calling nixos-rebuild through ssh?

Yes, although later I learned I could do it in a one-liner. Here nixconfig is a folder with all my nix files:

  tar -czf - nixconfig | ssh 192.168.1.1 \
    'tar -zxf - && sudo cp -r ./nixconfig/* /etc/nixos/ && sudo nixos-rebuild --show-trace '"${rebuild_flag} ${name_flag}"

Re: Nix: Taming Unix with Functional Programming

#158

Earlier quoted context omitted.

Yup. I started with Nix a little over a year ago on Nix 2.3, and have only ever used flakes and the new CLI. It's complete from my point of view— the main issue is just that the pills and all the official documentation still refer to the old commands. I wish they'd flip it over to being the default and update the docs. I know that's not trivial, and it's hard when all the long-time community members have the legacy c…

I started with a single system on NixOS around February of this year. I just recently saw an example of `nix search` instead of `nix-env -qaP`. I haven't seen any documentation for all of this new stuff. Any place to go, or do we just have to go read the source code?

`nix --help`, `nix search --help`, ... will show a man page, but a look at source can't hurt, as there are a couple of rough corners with the `nix` command that can be rather confusing.

For example `nix profile remove REGEX` will only match against the attribute part of the URL, which for Flakes is often just "defaultPackage.x86_64-linux", completely missing the name of the actual package, thus making it impossible to remove packages by name (using the index number will work).

The source is pretty readable:

https://github.com/NixOS/nix/tree/master/src/nix

Re: Nix: Taming Unix with Functional Programming

#159
post #142

Earlier quoted context omitted.

> minimalistic The Nix language is far more minimalistic than any Scheme. I have nothing against Scheme but let's be clear, Nix out-Schemes Scheme in this regard.

People complain about learning 'the language' when the thing they've really been trying to learn is actually: - the language - the stdlib (nixpkgs.lib) - the NixOS module system - several particular packaging ecosystems (stdenv, buildGoModule, buildPythonApplication, etc.) - the hooks and stuff that get exposed as variables and functions in bash-based builders all at once! (plus maybe even the derivation format) It m…

I definitely agree.

I want Nix to "show off" its layering a bit more for many reasons, but one of them is to hopefully allow for a more gradual curriculum.

Re: Nix: Taming Unix with Functional Programming

#160
I think Nix is great to add dependencies to your project without relying on your local env or separate Docker containers for that. We use it for bob[1] and so far Nixpkgs proved very valuable. It's amazing how many packages are pushed by the maintainers, there are over 80 000 packages there.

One problem would be when you don't find the package on Nixpkgs and have to write your own expressions to build a package.

https://bob.build/docs/getting-started/package-management

Post reply on HN