nix is a subset of json. If that’s a “hard” language, I don’t know what to tell people. Try GUIX with scheme?
This ignores how modules and flakes work. You often have to write function expressions, not just pure “JSON”, and it’s often unclear what the function parameters are supposed to be (at least for a beginner).
NixOS search exists so I’m not sure why it’s considered “hard to find packages”
The search is great and includes a ton of stuff, but there’s a lot that’s hard to install through it. For example, how do you install an application through Flatpak? How do you install extensions for Firefox or vscodium? How do you install a specific version of an application on an older nixpkgs commit while still installing the current version of other programs through a flake? (I’m guessing through multiple nixpkgs inputs?) How do you install something not in nixpkgs? (A custom derivation, but it’s not easy to build one if you’re a beginner or don’t understand what the program needs during build.)
These are all things that can be done, but there’s really no specific documentation to help with it.
What Nix really needs is better documentation and a commitment to (or against) flakes. Once it reaches that point, I think I’d consider it mature enough to recommend. I’ve definitely brought it up at work as an alternative to devcontainers, but it’s a hard sell for a lot of people because it’s so much harder to learn. Personally I use a shared HM config across all my machines, and it’s awesome, but I don’t know anyone else personally who has been able to figure it out.
Well said. I’m glad people are challenging my json characterization. I deserve the flack but perhaps it was just a sensationalist headline to get some discussion going. It worked. ;)
Thanks for the valuable anecdotal evidence. You do speak the truth. I’ve settled on the fact that the community will never agree to adopt flakes.
Personally, I have an opinionated stack that is, at this point, self documenting. I maintain a strict style where I add assertions to most things that nix won’t be able to prove conclusively with just a build and cheaper checks that I run before actually building any real derivations. As I said elsewhere, Nix feels like the revolutionary precursor to a sea change in dependency management. But it’s just that: an imperfect technology with enough great ideas for me to adopt it wholesale and use fixing and finding ways around the warts as a way to give back to this open source community.
This ignores how modules and flakes work. You often have to write function expressions, not just pure “JSON”, and it’s often unclear what the function parameters are supposed to be (at least for a beginner).
The search is great and includes a ton of stuff, but there’s a lot that’s hard to install through it. For example, how do you install an application through Flatpak? How do you install extensions for Firefox or vscodium? How do you install a specific version of an application on an older nixpkgs commit while still installing the current version of other programs through a flake? (I’m guessing through multiple nixpkgs inputs?) How do you install something not in nixpkgs? (A custom derivation, but it’s not easy to build one if you’re a beginner or don’t understand what the program needs during build.)
These are all things that can be done, but there’s really no specific documentation to help with it.
What Nix really needs is better documentation and a commitment to (or against) flakes. Once it reaches that point, I think I’d consider it mature enough to recommend. I’ve definitely brought it up at work as an alternative to devcontainers, but it’s a hard sell for a lot of people because it’s so much harder to learn. Personally I use a shared HM config across all my machines, and it’s awesome, but I don’t know anyone else personally who has been able to figure it out.
Well said. I’m glad people are challenging my json characterization. I deserve the flack but perhaps it was just a sensationalist headline to get some discussion going. It worked. ;)
Thanks for the valuable anecdotal evidence. You do speak the truth. I’ve settled on the fact that the community will never agree to adopt flakes.
Personally, I have an opinionated stack that is, at this point, self documenting. I maintain a strict style where I add assertions to most things that nix won’t be able to prove conclusively with just a build and cheaper checks that I run before actually building any real derivations. As I said elsewhere, Nix feels like the revolutionary precursor to a sea change in dependency management. But it’s just that: an imperfect technology with enough great ideas for me to adopt it wholesale and use fixing and finding ways around the warts as a way to give back to this open source community.