Comment by z_mitchell
15 days ago
I think that's a bit reductive, but I get the intent. A lot of people see systemic problems in their development and turn to tools to reduce the cognitive load, busywork, or just otherwise automate a solution. For example "we always argue over formatting" -> use an automated formatter. That makes total sense as long as managing/interacting with the tool is less work, not just different work.
With Nix I still think it's a net positive, but the "different kind of work" side of the equation is pretty large. That's why we're building Flox [1]. The imperative user interface of a package manager (flox install, flox search, etc) that builds out a declaratively-configured, reproducible, cross-platform developer environment. I really think it nails the user experience by keeping that "different work" side of the equation small, and (I hope) just gets out of your way.
[1]: https://flox.dev
I just started using Flox last weekend and so far it has been quite nice experience. There are two things I don't like, though:
1) The Homebrew package is a cask that installs also Nix. While I like Flox, I don't want my systems to be married to it. Yes, I know about install option with "generic Nix", but I'm using Homebrew with Brewfile both in macOS and Linux, and I would like the Homebrew package to be just Flox.
2) Documentation is OK for getting started, but not for anything more than that. There are nice manifest.toml examples for many use cases in floxenvs[1] but you need to find those first. Also I'm not sure how I feel about inline shell scripts in toml. While it works, separate files would be easier to handle, at least for me.
[1]: https://github.com/flox/floxenvs
There’s a small number of us working on the docs and we actually just did a pass over them before the holidays to evaluate how well they help users get things done. We took some action items from that that we’ll be working in over the next few months.
That said, the repo is public[1] and if there’s specific things you’d like to see or would find helpful you could open an issue. That would be really helpful, but there’s obviously no obligation to do so.
[1]: https://github.com/flox/floxdocs
Quickly skimmed through the Flox site and it looks like it’s based on Nix. The problem with the competitor https://www.jetify.com/devbox and most likely in Flox is that Nix makes trivial environment setup really easy but when you need something more complex it falls apart because the Nix packages are often unmaintained and simply broken.
It uses Nix under the hood.
I would argue that Nix does not make trivial environment setup easy. One of the reasons I love Flox for my own development is that I can just "flox install" packages. That doesn’t really exist for project-specific packages with Nix ("nix profile install" exists, but that installs globally). I would say give Flox a try and see if you actually run into issues. If you do, we're pretty good about fixing them as they come up.
It has also not been my experience at all that Nix packages are "often unmaintained and simply broken." I use Nix every day for work, and I use it to configure all of my personal machines (on both macOS NixOS). Can't say that's ever really been a problem for me.
In my case I couldn’t get Rust working and ran into strange compilation issues with linker errors with the MacOS standard libraries. Tried installing them from Nix which fixed some problems but caused other ones.
Everything just worked outside of the Nix environment so ended up dropping it.
1 reply →