[trinix912]

That's mostly solved with env managers for python/ruby/node/..., takes at most a few minutes to fully set up and learn, and doesn't get constantly broken by macOS updates.

Even for things like trying out a new shell you can temporarily move the dotfiles somewhere and restore them back and it still takes less time than converting everything to Nix.

[vegabook]

But now you’re stuck with Python. Nix enables trivially simple dev environments that are completely heterogenous. This gives you a powerful form of freedom because it literally opens up the entire software universe to your dev environment in a confidence inspiring way. Not to mention things like parameterising anything you use reliably and setting up environment variables, shell scripts, database service whatever you want. Also integrates with tools such as UV really well. Yes, the language is terse and difficult but once you know it, it’s liberating, and makes you a better software developer in my opinion because you now have a high-end full workshop rather than a small toolbox.

[yladiz]

This is my feeling too. Nix is a relatively high time investment for a tool that tries to do everything, when you might not need or want everything and using the specific language’s tooling is more than sufficient and quicker. It takes a few minutes to install and do `uv sync`, or `nvm install`, or whatever, on a repository on a new computer, and it just works. Until Nix gets there, and I’m skeptical it will because of the “purist” mindset a lot of people in the community have, it’s hard to justify it.

[rgoulter]

I think the comparison is "X-as-code", like with Terraform and other tools.

If you just want a throwaway VM, it's straightforward to create one through the UI cloud console. Whereas, terraform is nevertheless still a useful tool to use to manage VMs.

For stuff like installing development dependencies.. it's maybe not difficult to copy-and-paste instructions from a readme, but solutions like devcontainers or Nix's development shells can be useful even if costing more overhead.

[yladiz]

Of course. I wouldn’t say that Nix is a tool without much use or merit, because setting up development environments can be a huge pain and I understand why some people would use it and prefer it.

My biggest complaint is what I mentioned above: it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to - I might have to debug Nix instead of Node, which is not always straightforward. In my limited experience Nix got in my way more than I’d like, and in ways I didn’t expect or want to deal with, and until it’s as seamless as something like Homebrew or apt, it’ll be a hard sell.

[rgoulter]

> it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to

Although you're right about nix's DX being quite rough, the problem isn't exactly that it "tries to be everything for package management".

Consider the assumption Nix wants to make about its packages: it should be possible to package software by putting it in some arbitrary directory (i.e. not just /usr/bin), where its dependencies are also put in (or symlinked to) some arbitrary location.

I think with well-written software, this should be a reasonable assumption, but you're going to run into friction with that. (Friction which will require you to have a good breadth/depth of understanding).

In my experience, a lot of the complexity when dealing with Nix is with the large and organic complexity of nixpkgs.

The "trying to be everything" is more incidental to the expressive package management. -- NixOS is 'just' an OS built upon the package manager; dev shells are 'just' shells which expose the build environment of a package; etc.

[pjmlp]

Fully spot on, I don't get what is that hard to set a couple of environment variables, and mayby symbolic links, depending on the OS and language being used.

A simple UNIX script or PowerShell utility takes care of it.

None of the ones I have used during the last decades has ever grown to more than like 20 lines of code, minus comments.

[rgoulter]

> Even for things like trying out a new shell you can temporarily move the dotfiles somewhere and restore them back...

I think the closest mainstream UX for "you can try out this program without having to install it" is running a Docker image.

:) I'd say Nix is second best at everything related to packages.

[vegabook]

until you need to start combining things. Docker is conceptually a VM the encapsulates everything nicely, but it ironically doesn't "compose" nearly as well as nix flakes or shells. With Nix you start out with a base env and can trivially extend it hierarchically and jump up and down the tree super easily, and without having to roll your own microservice architecture each time just to get stuff to work together.

[chuckadams]

Docker OTOH composes whole services nicely: if my project needs a redis cache and postgres instance, I don't have to faff about with local ports, traefik can pick up my web server, and so on. I use a flake to create and lock a local development toolchain, but it's no help in managing the services.

One thing I haven't tried yet is building a container from a flake, which would have obvious benefits for reproducibility. Still don't think it would help with service orchestration though.