deleted by creator

Active GuixSD user.

Our application catalog is much smaller than many other distros simply because we don't have the userbase large enough to surface the volunteers necessary to support it. So you will have to learn to write your own packages eventually

That said, if you know your way around functional languages (in this case, scheme), it's probably the easiest time I've ever had writing a package. Everything that goes into the script is known at the time the script is written, so weird extrinsic problems don't really occur after you've written the package.

Some stuff that you and the guix maintainers may not have the time to support will also get updated more slowly.

Luckily flatpak exists, and is a godsend for the new wave of read-only (functional/ostree-based) OSs.

Biggest appeal for me was having all my configuration in one place (and documented) so if I forget I did something in 6 months, it's always staring at me in my home or system config file. You can accomplish the same thing by being diligent with say, script files, but it's drop-dead easy to just maintain a system and home descriptor file and keep editing that.

I wanted to love nixos but it has many shortcomings that aren’t immediately obvious but can really stump you. No FHS compatibility seems fine but certain programs require it and don’t have nix native workarounds. Additionally, the documentation is really not good. I used it for a while but it got in the way too much; now I use a fedora variant and use regular Nix for dev packages using nix-direnv. Gives me the nix features while also having a fully compliant and functional base system

I use nixos for dev all the time, personally I think it's great

What I would suggest however is to install the nix package manager on another distro, learn how it works that way and then switch when you're comfortable only using nix

Flakes are absolutely incredible for development and I think every project beyond scrappy scripts should use them.

You can specify all your dependencies (compiler, libraries, cli tools, environment variables etc) in your nix flake, then run nix develop and it'll make you an isolated shell with all that stuff

(For example, I don't have go, rust or dotnet installed but when I cd into one of my projects directors it installs them to a temporary shell and catches them until I clean up)

The flake also generates a lock file which specifies every version of every dependency with a git rev and a hash, meaning if you check flake and lock into git, anyone else who clones that project and uses the flake gets the exact same system you were using

Question: What are you developing?

With that said, NixOS would probably be fine, if not better than fine. From what I can tell, I don't think Guix would be a good idea - the packages appear out of date, according to their package manager. They're still on Python 3.10.

However, I might recommend Debian Testing to you for your purposes. Most of the time, packages are pretty recent, maybe a few months old at the most (sometimes just a few weeks), but you still get most of the stability of regular Debian. The only asterisk is when the freeze happens. I think apt may have gotten some updates as well.

I've been using it on my desktop PC for over two-and-a-half years. I will say I have grown a bit weary of it, as it gets so many updates and software changes so fast. On my laptop, I went with stable and plan to switch or stable on my desktop once Trixie gets stable.

In brief, Testing isn't bad. I'd almost recommend a development VM.

I went from Arch to NixOS, so I can offer a bit there.

You definitely won't want to rely on it until you know a good amount and get comfortable. Things can be made to work, but knowing how to get it done is the main thing most of the time.

Regarding package availability, it's just a matter of a few oddly esoteric incantations and version controlled code, usually. Binaries are another story but still possible, and python is a special case of that.

It has been an annoyance for me, but I've also learned a lot by getting things to work. If you use any niche python stuff you're bound to run into something. A bunch is already packaged and works fine, though. Either way there's a bit of extra nuance, which is more to learn.

You don't have to start with NixOS and can feel it out using nix on any distro. It can be hard to tell if someone will vibe with it. All that said, it could be more than you're looking to get into, but you can ease into it if you're interested.

I use Guix Home on my laptop (on top of Asahi Fedora Remix) and started trying to use Guix System on my server a while ago. Here's some points I have:

• The declarative configuration system is fucking awesome and makes Debian feel like the stone age. It does have a high learning curve though but it is definitely worth it.
• When deciding between Nix vs Guix, I ended up settling on Guix because Nix seemed more focused on marketing and cutting corners to make a working product faster and Guix seemed more like a community project with better ideological goals behind it. However, I have hardly used Nix so take this with a grain of salt. Also, Nix has a lot more packages and is closer to being production-ready and in a business setting I would probably choose Nix for the project instead because of that, it also is compatible with macOS and Guix isn't.
• The Guix package manager is source-based and the repos are committed to 100% free software which I really like compared to Nix which just throws binaries in their repos. However, this means that they need to package everything to work within their ecosystem as if they are packaging for an entirely different OS, and this is often very time-consuming, especially for packages with hundreds of dependencies. Combine that with the community being very small and niche, and repo under-maintenance is a very serious problem. Many core packages are outdated, which also seems like a security hazard. If you're expecting to use a bunch of new Rust-hype programs or something that isn't mainstream, they probably aren't there (you may find them in an obscure third party repo however). Some core libraries made significant changes to their build process when they updated that haven't made their way to Guix so they may be stuck on an old version until someone decides to update it. If there's a package you need, expect to either package it yourself or download it with a different package manager like Nix or Flatpak.
• Most modern hardware requires proprietary blobs and you'll need the nonfree Linux kernel from the nonguix repo. SystemCrafters has an installer image that comes with that IIRC.
• You may be interested in an "Erase Your Darlings" system configuration (do not save filesystem state to disk except for files/folders explicitly opted-in, requires even more upfront configuration but helps ensure reproducability). Nix has that built in. Guix doesn't, but if you fuck around enough with the partitioning you can get it to work. I have a setup with BTRFS and subvolumes that took me a week to figure out and I had to do some hacky setting to make it work correctly with Grub. Also it's more difficult to do when you don't know how Guix's file structure is laid out or are unfamiliar with the tooling and configuration language, there aren't really any good tutorials on the internet for it either so lmk if you need any help (it doesn't have disk encryption however since it is on a VM).
• If you want to make sure your system stays pinned to specific software versions, the way I do that is I have a channel.scm which has the channels like normal. Using the just command runner, I have a Justfile in the directory where I store my configuration. just update runs guix time-machine pointing to the channel.scm which pulls the repo's updates then after the -- has the command that prints the channels with the specific commit to channel.scm.lock. For every other guix command, such as the reconfigure command, it uses guix time-machine pointing to channel.scm.lock then the command I want after --.
• Flakes is probably the most hyped feature about Nix, which instead of using a central repo for all software lets each project turn their git repo into a source for the package manager which can point to other repos it depends on. Guix doesn't really have this feature, but since its main goal is creating an ecosystem of completely free software, I would argue that the centralized approach is better for this project since it helps GNU achieve this goal and provides guarantees about the freedom of the software and the packaging quality. Guix also makes it easy to create your own repo for packages or turn your project into a repo for a package, but it can't refer to packages outside of the repos that are listed as sources on your local setup so it isn't really flexible like Flakes.
• It also uses Shepherd for its init system which uses the same configuration language as the rest of the system. Compared to systemd I am not sure which is principally better, however it provides an additional roadblock to packaging software since most stuff is designed around systemd-based distros.
• This project is niche and has very few resources for help aside from the documentation, the source code (there seems to be quite a bit of undocumented stuff so you'll probably end up browsing it sooner or later), IRC/mailing lists, SystemCrafters, and a few random blogs or git repos. ChatGPT fucking sucks at Guile and it spits out code that is about 80% incorrect so actually learn Guile and don't use ChatGPT (sometimes it gets the parenthesis wrong too which is kindof hilarious).
• Setting up Emacs, a local SMTP server connected to your email for git, and a CLI password manager will probably be helpful.
• Have a copy of Guix cloned on your computer so you can browse around and see how stuff works (especially packages and services). It's the same language as the system configuration language which is helpful. The documentation also has a guide to set it up for contributing which you may be interested in at some point.
• The contribution process is weird, it uses a lot of command line tools which I kindof like but it also has a learning curve which doesn't help with the contributor shortage. Also it seems like a lot of patch requests get ignored and in some cases how to contribute is confusing. I was trying to contribute a Rust program once but it added hundreds of libraries and when I submitted it months ago it got ignored so I don't know how I am supposed to contribute these sort of programs and the mailing list/IRC didn't give me much advice either.
• For finding packages, there's https://toys.whereis.みんな/ which shows stuff from nonguix and other repos you'll probably want.
• For making your own packages, the guix import feature can be helpful and works nicely with Rust, especially if the program you want is in crates.io in which you can put it in your packages repo very quickly.
• For using Guix for software projects, there aren't a ton of libraries packaged so you'll need to see if your language is supported by guix import. The Node.js ecosystem is allergic to FOSS so it might not work very well with Guix (there are barely any Electron programs packaged outside of nonguix also).
• guix profile and guix home are confusingly different. One uses imperative install commands and the other uses a declarative configuration and they install into different directories, so if you remove a program from home but it's still there it may still be installed in profile.
• Most packages should be installed using guix home and don't need to be installed systemwide. It also provides powerful containerization/environment management tools to isolate installs efficiently.
• For server stuff, Shepherd has a sandboxing feature I've experimented with a tiny bit that isn't well documented (if at all), I haven't tested it in a while though but with it you don't really need to containerize stuff. I haven't figured out how do manage the networking correctly but there's probably ways to do that as well.
• For servers, trying to package Node projects that aren't in a single binary sucks.
• For desktop usage, I would recommend installing Guix Home on your current distro first and experimenting with that before doing a full system install (which is what I'm doing right now since being on a Macbook adds additional complications). You can do the same thing with Nix home-manager also.
• Guix and SELinux don't really get along, on Fedora you may need to disable it (I don't know how to use it correctly with Guix) which weakens security (which on Linux security kindof sucks). This is a problem with Nix as well.

To address your points:

The Debian/Fedora based ones seem to be fairly slow to update and so they have out of date packages, which sometimes is ok, but sometimes if they are too out of date I have to compile it from scratch.

Fedora is way more up-to-date than Guix is. Also Guix is source-based so it may end up compiling stuff from source automatically. You can install Nix though if you need it which looks a lot more up-to-date.

I end up spending a lot of time configuring stuff that isn’t built in

You'll be spending a lot of time configuring stuff with Guix as well. However the declarative style makes it a lot easier to track and maintain.

having stuff randomly be broken after an update

Libcamera broke pretty recently on my Guix install which broke a ton of programs although it might be fixed now. If that happens though you can revert to your previous configuration or pin the repo to an older version until it gets resolved. Normally packages are checked when they are updated though to ensure they don't break stuff.

I don’t have a lot of time to mess around with configuring stuff all the time.

You'll need to spend a lot of time learning stuff since there's very few tutorials on the internet.

Ideally I’m looking for a distro that works well with my old-ish hardware (with NVIDIA support unfortunately)

IDK if nonguix supports NVIDIA or not but it might be a problem.

if the library is designed to use like ‘pip’ or ‘bun.sh’ or some built in package manager

You can still use other package managers, but you can't use them to package the program specifically for Guix. You may have luck using guix import instead however. Also bun.sh is an example of a non-mainstream program that probably isn't in the Guix repos.

You answered the most important question when another person asked it.

You aren’t developing anything, so a distribution for development wouldn’t be necessary. If it were, it would be the distribution closest to the target environment.

You’re learning, and anything is fine. Someone said Debian testing, that’s a good choice. You just want stuff to work and spend the barest minimum amount of time fiddling around with your environment so probably not Linux at all.

You’ll find that the overwhelming majority of support materials in every language you listed will use windows or can be effectively used in windows. If you really need the Unix environment, they will probably first have examples in macos.

So maybe consider using windows or macos.

You’re not going to have an easier time learning2code on some esoteric distribution.