The confusion arises because there are 5 different ways to do the same thing, the non-experimental methods shouldn’t be used even though they’re recommended in the official docs
I appreciate what you’re trying to say, but you’re kind of illustrating exactly the point I was making about conceptual simplicity and atrocious UX.
You’re ignoring the difference between using something declaratory and imperatively. Just because it’s difficult to get to that one liner, it doesn’t change the fact you’ll still only use that one command. Git by it’s nature requires you to use different commands to achieve different results. Home-manager allows you to both update your packages and delete all of them with the same command, because that command is “sync the state with the source of truth”.
I don’t really care about the declarative/imperative thing, to me how many commands you “really need” is beside the point. This is essentially the same argument as the people who say “git is not complex because you only really need checkout/commit/push, just ignore all the other commands.” This doesn’t matter when the official documentation and web resources keep talking about the other billion commands. Even home-manager has this warning at the very top of the page that basically tells you “you need to understand all the other commands first before you use this,” and “if your directory gets messed up you have to fix it yourself.”
These are exactly the same kinds of problems people have with git.
I don’t really care about the declarative/imperative thing, to me how many commands you “really need” is beside the point.
Caring is not required, but you need to at least understand the difference.
This is essentially the same argument as the people who say “git is not complex because you only really need checkout/commit/push, just ignore all the other commands.”
It’s really not.
Stage,commit,push,fetch,merge,etc. are all commands you need issue to git in order to manually create a desired state. You need to know what you’re doing, and what to do differently if there’s an issue.
home-manager switch does all of it on its own. You don’t use a different cli command if something’s broken, you change the source of truth. All of the commands you might use in an imperative package manager like apt update/upgrade/install/remove are instead that one command.
Even home-manager has this warning at the very top of the page that basically tells you “you need to understand all the other commands first before you use this,” and “if your directory gets messed up you have to fix it yourself.”
It’s quite a disingenuous interpretation of “beware: home-manager uses the nix language and so gives nix language errors” and “choosing to create configuration files might overwrite the existing ones for that package”…
If you’re using a programming language, expect error messages specific to that language/compiler/interpreter/whatever. And it’s not like every other PM is using standardised error messages, you still need to learn to read them.
Config files aren’t generated randomly, you need to manually enable the configuration of each package. If someone is capable of getting to the info required to know how to configure a package, it’s reasonable to expect that they can guess that changing a config might overwrite the existing one.
These are exactly the same kinds of problems people have with git.
Do tell me how you can solve git problems without changing the git commands.
You’re essentially saying that the terraform cli has the exact same problems as the aws cli, and that’s just ridiculous. They both let you host your blog, but they do it in a completely different way and therefore have different issues.
Nix has the same mix of conceptual simplicity and atrocious user interface as git,
Nobody at any point compared the difficulty of learning the entirety of each of those systems, and my entire point is that the complexity of nix is not in the cli commands…
I appreciate what you’re trying to say, but you’re kind of illustrating exactly the point I was making about conceptual simplicity and atrocious UX.
You’re ignoring the difference between using something declaratory and imperatively. Just because it’s difficult to get to that one liner, it doesn’t change the fact you’ll still only use that one command. Git by it’s nature requires you to use different commands to achieve different results. Home-manager allows you to both update your packages and delete all of them with the same command, because that command is “sync the state with the source of truth”.
I don’t really care about the declarative/imperative thing, to me how many commands you “really need” is beside the point. This is essentially the same argument as the people who say “git is not complex because you only really need checkout/commit/push, just ignore all the other commands.” This doesn’t matter when the official documentation and web resources keep talking about the other billion commands. Even home-manager has this warning at the very top of the page that basically tells you “you need to understand all the other commands first before you use this,” and “if your directory gets messed up you have to fix it yourself.”
These are exactly the same kinds of problems people have with git.
Caring is not required, but you need to at least understand the difference.
It’s really not.
Stage,commit,push,fetch,merge,etc. are all commands you need issue to git in order to manually create a desired state. You need to know what you’re doing, and what to do differently if there’s an issue.
home-manager switchdoes all of it on its own. You don’t use a different cli command if something’s broken, you change the source of truth. All of the commands you might use in an imperative package manager like apt update/upgrade/install/remove are instead that one command.It’s quite a disingenuous interpretation of “beware: home-manager uses the nix language and so gives nix language errors” and “choosing to create configuration files might overwrite the existing ones for that package”…
If you’re using a programming language, expect error messages specific to that language/compiler/interpreter/whatever. And it’s not like every other PM is using standardised error messages, you still need to learn to read them.
Config files aren’t generated randomly, you need to manually enable the configuration of each package. If someone is capable of getting to the info required to know how to configure a package, it’s reasonable to expect that they can guess that changing a config might overwrite the existing one.
Do tell me how you can solve git problems without changing the git commands.
You’re essentially saying that the terraform cli has the exact same problems as the aws cli, and that’s just ridiculous. They both let you host your blog, but they do it in a completely different way and therefore have different issues.
So you’re saying that it’s easier to learn C++ than git, because you only need one command (
g++ foo.cpp -o foo) instead of many?In case you missed topic of the whole discussion:
Nobody at any point compared the difficulty of learning the entirety of each of those systems, and my entire point is that the complexity of nix is not in the cli commands…