5 ms·

"We want Nix to ne ubiquitus" And there it is. Every time I hear about Nix, the goal is to convince me to adopt it, as if it was some kind of religion. Every t

"We want Nix to ne ubiquitus" And there it is. Every time I hear about Nix, the goal is to convince me to adopt it, as if it was some kind of religion. Every time the Nix folks are being too pushy about it. Just stop pestering random project maintainers with Nix. If a project maintainer likes Nix, they'll add the Nix files. If they don't have Nix files, that doesn't mean they want to sign up for Nix advertising.

cmm 4y ago
who addressed to? who's pestering you?
amelius 4y ago
> as if it was some kind of religion I don't know of a religion where you have to go through hell before reaching heaven.
- classified 4y ago
  git, for instance, became mainstream in spite of that.
- LunaSea 4y ago
  Christianity?
blueflow 4y ago
I agree. At $dayjob, we are currently employing a nix consulting company comparable to the one in the link. They are very vocal about all the great things Nix is able to do, but when we actually attempt to do something in Nix, we run into countless bugs and problems, including inaccurate documentation. Unfortunately many private FOSS enthusiasts do not know that reliability and documentation is a must for serious engineering environments. Plus, a coworker pointed out that while its supposed to be pure and functional, many recipes still basically wrap a shell script. So its not that far from the build system we already have...
- microtonal 4y ago
  many recipes still basically wrap a shell script Not defending Nix here, but using shell script as part of the build doesn't make Nix itself imperative/impure. As long as the evaluation of the Nix expression itself is pure [1], the build inputs are fully specified, and the build is performed in a sandbox, the shell script (and things like configure/cmake/make/ninja) should always be run in the same manner and result in the same output (modulo things like embedded time stamps in files). [1] This hasn't traditionally been true, since you could e.g. read files or use environment variables from Nix, but this is something flakes address.
- rgoulter 4y ago
  > So its not that far from the build system we already have. Yup. The key contribution Nix brings is arranging the outputs of builds into the nix store, in such a way that you can trust that building a package with the same set of inputs will result in a package that behaves the same way. (This then allows e.g. different versions of the same package). There's some friction, since with some software, if you try and build things but disallow writing to arbitrary files (e.g. no writing to $HOME), the tools might have assumed they could, so things might not work. -- That's 'purity' in some sense, in that what inputs the package building uses is totally declared. I liked the analogy introduced from a tweag post from a couple of weeks ago https://www.tweag.io/blog/2022-07-14-taming-unix-with-nix/ https://www.tweag.io/blog/2022-07-14-taming-unix-with-nix/ (big discussion yesterday https://news.ycombinator.com/item?id=32355327 https://news.ycombinator.com/item?id=32355327) that illustrated nix as 'pure', but interacting with the Unix system by way of files. -- You have a pure way of managing an impure system. (Which is loosely comparable to how Haskell can be pure, but still do impure stuff like Input/Output).
- _hl_ 4y ago
  > But when we actually attempt to do something in Nix, we run into countless bugs and problems, including inaccurate documentation. This is really unfortunate. Unless you invest time into learning which paths to walk, you're not going to have a great experience with Nix. That just doesn't scale to modern engineering teams, you can't expect everyone to know everything. > Plus, a coworker pointed out that while its supposed to be pure and functional, many recipes still basically wrap a shell script. So its not that far from the build system we already have... It's true that a lot of nix expressions boil down to a shell script. But by default they're running in a sandboxed environment that can be exactly replicated and guarantees (mostly) reproducible results. And that's great - after some ceremony to set everything up, Nix lets you work with the tools you already know, but puts them into a reproducible environment.
SkyMarshal 4y ago
I love NixOS, use it on all my workstations (and Nix on my Mac) and could never go back to a normal Linux. But I agree, they need to drop or reword that as an official goal. I suspect what they're thinking is that they want it to become so good and more broadly accessible to a wider range of developers that it gets natural usage and traction and becomes ubiquitous organically. But they make it sound more like they're missionaries proselytizing a religion, ostensibly for the audience's benefit, but really more for the religion's benefit. Or salesmen selling something by telling you how good it is for you, when it's really better for the salesman. People pick up on that and reject it. Of course, they should keep trying to make Nix ubiquitous by making it really good and broadly accessible and by engaging with the dev community for ideas on how to do that, as they outline in this post. Just don't make ubiquity an official goal. Let that happen organically.

cmm 4y ago

who addressed to? who's pestering you?

amelius 4y ago

> as if it was some kind of religion I don't know of a religion where you have to go through hell before reaching heaven.

classified 4y ago
git, for instance, became mainstream in spite of that.
LunaSea 4y ago
Christianity?

blueflow 4y ago

I agree. At $dayjob, we are currently employing a nix consulting company comparable to the one in the link. They are very vocal about all the great things Nix is able to do, but when we actually attempt to do something in Nix, we run into countless bugs and problems, including inaccurate documentation. Unfortunately many private FOSS enthusiasts do not know that reliability and documentation is a must for serious engineering environments. Plus, a coworker pointed out that while its supposed to be pure and functional, many recipes still basically wrap a shell script. So its not that far from the build system we already have...

microtonal 4y ago
many recipes still basically wrap a shell script Not defending Nix here, but using shell script as part of the build doesn't make Nix itself imperative/impure. As long as the evaluation of the Nix expression itself is pure [1], the build inputs are fully specified, and the build is performed in a sandbox, the shell script (and things like configure/cmake/make/ninja) should always be run in the same manner and result in the same output (modulo things like embedded time stamps in files). [1] This hasn't traditionally been true, since you could e.g. read files or use environment variables from Nix, but this is something flakes address.
rgoulter 4y ago
> So its not that far from the build system we already have. Yup. The key contribution Nix brings is arranging the outputs of builds into the nix store, in such a way that you can trust that building a package with the same set of inputs will result in a package that behaves the same way. (This then allows e.g. different versions of the same package). There's some friction, since with some software, if you try and build things but disallow writing to arbitrary files (e.g. no writing to $HOME), the tools might have assumed they could, so things might not work. -- That's 'purity' in some sense, in that what inputs the package building uses is totally declared. I liked the analogy introduced from a tweag post from a couple of weeks ago https://www.tweag.io/blog/2022-07-14-taming-unix-with-nix/ https://www.tweag.io/blog/2022-07-14-taming-unix-with-nix/ (big discussion yesterday https://news.ycombinator.com/item?id=32355327 https://news.ycombinator.com/item?id=32355327) that illustrated nix as 'pure', but interacting with the Unix system by way of files. -- You have a pure way of managing an impure system. (Which is loosely comparable to how Haskell can be pure, but still do impure stuff like Input/Output).
_hl_ 4y ago
> But when we actually attempt to do something in Nix, we run into countless bugs and problems, including inaccurate documentation. This is really unfortunate. Unless you invest time into learning which paths to walk, you're not going to have a great experience with Nix. That just doesn't scale to modern engineering teams, you can't expect everyone to know everything. > Plus, a coworker pointed out that while its supposed to be pure and functional, many recipes still basically wrap a shell script. So its not that far from the build system we already have... It's true that a lot of nix expressions boil down to a shell script. But by default they're running in a sandboxed environment that can be exactly replicated and guarantees (mostly) reproducible results. And that's great - after some ceremony to set everything up, Nix lets you work with the tools you already know, but puts them into a reproducible environment.

SkyMarshal 4y ago

I love NixOS, use it on all my workstations (and Nix on my Mac) and could never go back to a normal Linux. But I agree, they need to drop or reword that as an official goal. I suspect what they're thinking is that they want it to become so good and more broadly accessible to a wider range of developers that it gets natural usage and traction and becomes ubiquitous organically. But they make it sound more like they're missionaries proselytizing a religion, ostensibly for the audience's benefit, but really more for the religion's benefit. Or salesmen selling something by telling you how good it is for you, when it's really better for the salesman. People pick up on that and reject it. Of course, they should keep trying to make Nix ubiquitous by making it really good and broadly accessible and by engaging with the dev community for ideas on how to do that, as they outline in this post. Just don't make ubiquity an official goal. Let that happen organically.