4 ms·

Something will evolve from that space which doesn't have the flaw. Whether that thing will be called Nix or not, I don't know. I think that means that it's no

Something will evolve from that space which doesn't have the flaw. Whether that thing will be called Nix or not, I don't know. I think that means that it's not a fatal flaw, it's just a regular flaw.

jamies 3y ago
I totally agree. I love and hate Nix every day that I use it. I hope that someday they'll make it more user friendly, but I suspect it'll be someone else with a new approach.
- tempay 3y ago
  I struggle to see how another tool will take the spot. I think the power of Nix is that the underpinnings are so pure, academic and well thought out that you can rethink package management in a much cleaner and sane way. Unfortunately that results in the UI not being the priority, though I think the opposite approach results in a conventional package manager with their many flaws and trade offs. I generally think the UI first approach is a better way of building tools, but there are special cases where it doesn’t work due to their being so many edge cases that you need pure underpinnings to make it actually work (e.g. version control).
  - abathur 3y ago
    I feel this. I ~empathize with people who wish it were simpler, and agree there are too many sharp corners. (For example, the traditional CLI certainly left a lot of room for improvement.) I can vaguely imagine the prospect that something new gets this more-right than Nix, but on some level I also suspect most ~complainers aren't appreciating the scale of the domain complexity Nix closes over in order to forge The Nix Way and square decades of contrary software development/packaging/deployment practices with it.
aidenn0 3y ago
I'm not convinced that the upsides of Nix don't necessarily include the downside. Docker files are basically "copy these files in and run these commands with full network access" which is a recipe for both "easy" and "not reproducible" Oh, I need python? "RUN apt-get install -y python" done. Which python version is installed? I don't have to think about that. If you want to ensure the inputs are the same, then you need to impose structure. That structure is a large part of what is confusing with Nix. I hate the Nix language as much as the next-guy, but I don't think that if it were Javascript instead, everyone would be like "oh this is so easy!"
- mise_en_place 3y ago
  It's no more difficult than packer. The challenge is architectural, because a lot of times (and I am guilty of this as a developer myself) the infra architecture comes later or after the fact.
- eternityforest 3y ago
  A lot of what makes declarative stuff nice is it comes with an implicit opinionated standard way of doing stuff. Nix tries to be way more general to the point of a whole programming language. Compare that with Snap packages: https://snapcraft.io/docs/python-apps https://snapcraft.io/docs/python-apps Where everything is closer to true configuration not declarative programming. Apt and PyPi packages in, snap package out, install it like it was an exe or put it in an app store, give it some permissions, done. They don't introduce any new concepts and there are few intermediate extra steps, it's all more of less pretty common ideas found in any tech workflow.

Something will evolve from that space which doesn't have the flaw. Whether that thing will be called Nix or not, I don't know. I think that means that it's not a fatal flaw, it's just a regular flaw.

jamies 3y ago

I totally agree. I love and hate Nix every day that I use it. I hope that someday they'll make it more user friendly, but I suspect it'll be someone else with a new approach.

tempay 3y ago
I struggle to see how another tool will take the spot. I think the power of Nix is that the underpinnings are so pure, academic and well thought out that you can rethink package management in a much cleaner and sane way. Unfortunately that results in the UI not being the priority, though I think the opposite approach results in a conventional package manager with their many flaws and trade offs. I generally think the UI first approach is a better way of building tools, but there are special cases where it doesn’t work due to their being so many edge cases that you need pure underpinnings to make it actually work (e.g. version control).
- abathur 3y ago
  I feel this. I ~empathize with people who wish it were simpler, and agree there are too many sharp corners. (For example, the traditional CLI certainly left a lot of room for improvement.) I can vaguely imagine the prospect that something new gets this more-right than Nix, but on some level I also suspect most ~complainers aren't appreciating the scale of the domain complexity Nix closes over in order to forge The Nix Way and square decades of contrary software development/packaging/deployment practices with it.

aidenn0 3y ago

I'm not convinced that the upsides of Nix don't necessarily include the downside. Docker files are basically "copy these files in and run these commands with full network access" which is a recipe for both "easy" and "not reproducible" Oh, I need python? "RUN apt-get install -y python" done. Which python version is installed? I don't have to think about that. If you want to ensure the inputs are the same, then you need to impose structure. That structure is a large part of what is confusing with Nix. I hate the Nix language as much as the next-guy, but I don't think that if it were Javascript instead, everyone would be like "oh this is so easy!"

mise_en_place 3y ago
It's no more difficult than packer. The challenge is architectural, because a lot of times (and I am guilty of this as a developer myself) the infra architecture comes later or after the fact.
eternityforest 3y ago
A lot of what makes declarative stuff nice is it comes with an implicit opinionated standard way of doing stuff. Nix tries to be way more general to the point of a whole programming language. Compare that with Snap packages: https://snapcraft.io/docs/python-apps https://snapcraft.io/docs/python-apps Where everything is closer to true configuration not declarative programming. Apt and PyPi packages in, snap package out, install it like it was an exe or put it in an app store, give it some permissions, done. They don't introduce any new concepts and there are few intermediate extra steps, it's all more of less pretty common ideas found in any tech workflow.