3 ms·

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 i

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.
pxc 4y ago
> 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... The shell scripts' effects get frozen in the Nix store, though, and can't be touched after build time. So it's a bit like using a loop in the implementation of an interface that that returns an immutable value in a language like Scala or something.
crabbygrabby 4y ago
Honestly switch out while you can. Sunk cost fallacy is a hazard for business. Could wrack up a million in consulting fees for a subpar tool here.

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.

pxc 4y ago

> 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... The shell scripts' effects get frozen in the Nix store, though, and can't be touched after build time. So it's a bit like using a loop in the implementation of an interface that that returns an immutable value in a language like Scala or something.

crabbygrabby 4y ago

Honestly switch out while you can. Sunk cost fallacy is a hazard for business. Could wrack up a million in consulting fees for a subpar tool here.