There's lots of ways nix can be used. It's framework and shell.nix lets you build any sort of environment you want. E.g. if you don't want to use the nixpkgs ruby, you could install rvm in the env and in the shellhook get the correct ruby. Or use the nixpkgs-ruby as you found out. It's relatively easy to pull any sort of nix libraries into your own .nix file (and even easier with flakes). The most powerful thing about nix is that every derivation is cached, so now you can have your own binary cache shared somewhere, and suddenly everyone's build times go down, especially useful for complicated dev environments.

For example, I cross-compile rust code to arm64, build websites, and deploy the whole infrastructure to AWS including the said rust code as AWS lambdas from a single nix derivation. The cross-compiling toolchains, etc take time to build, but then they are cached and only stuff that gets rebuild are the actual stuff I'm developing / changing. This is the backbone of nix really. You may not think this is not that amazing though, but nix is from ground-up built so that it's very difficult to write anything impure, anything that can't be cached or does not cache properly.

For my work, I've written shell.nix for every project I'm developing. This means my own personal environment stays clean, but for projects I always have the environment I need up in seconds. And if I start running out of space, I can just run nix-collect-garbage and forget about it. This is especially useful for me, as I do contract work and don't use the work PC just for one company.

I haven't actually yet used NixOS, but if I ever have to spin up new servers, I'm considering it.. I have ryzen machine that I use for gaming and sometimes building larger stuff... and I'm feeling like I want to migrate that to NixOS.. maybe someday .. :)

Also if you are an mac user, you really should do yourself a favor and switch away from homebrew

I was highlighting the difference in ease of use. While you can do anything in nix and provide versions you want, it's not as nicely wrapped as asdf. For some things supported by asdf, like elasticsearch, nix requires a lot more work. It's a bit like the old dropbox-via-rsync comment - it's true you can do these things through shell.nix, but that's not why people use asdf. There's space for a flake wrapper which will make things much easier.

Yeah I wish you could just start with a `.tools-version` and nix would generate a development flake. Someday!

That being said, the task of debugging a deprecated tool version in asdf just one time makes the investment in the nix awkwardness worth it.

the pitch for nix isn't that it's a nicer tool than, e.g. `asdf`, but rather, that it will probably work in five years. frightful flashbacks of of trying to get nokogiri to build.

Some people are doing these kind of wrappers, for example: https://github.com/luispedro/nixml

Machine learning people usually use anaconda which is all sorts of mess... But honestly yeah, I think it's worthwhile to invest learning nix for simply guaranteeing your environment still works for years to come and isn't affected by side-effects (some thing outside of your environment description actually is causing the whole thing to work, or some thing outside the environment is making the thing not work).

we're working on something like this :) Check out https://floxdev.com

Slightly off topic, but that page lags like crazy on ff mobile. I was trying to read/scroll it and it wasn't a great experience.

There is always the option of writing your own derivation for specific versions too, however.

I don't think mentioning Nix is meant to be sarcastic - this is a function the package manager has built-in by default, so it is worth mentioning.