6 ms·

I don’t want to be dismissive. “nix but with yaml” is kind of like saying “rust but without borrow checking”. if you think you can approximate what Nix is capab

by n42 5y ago

I don’t want to be dismissive. “nix but with yaml” is kind of like saying “rust but without borrow checking”. if you think you can approximate what Nix is capable of with YAML and be less complicated, I think you’ve missed the point. what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing. the language itself is surprisingly simple. the difficulty people have with it is that it’s functional, not that it’s nix. I don’t think most sys admins are fluent in functional programming, so it’s a huge turn off and learning curve. if you approach it as three problems: learn the basics of functional programming, learn the syntax of the Nix language, and only then learn what a derivation is and how it works, it will be a lot easier to approach. at that point the nixpkgs library starts to make a LOT more sense. I understand that’s a lot to ask when you just want to install some packages, though. It’s a tricky problem.

temptemptemp111 5y ago
dwohnitmok 5y ago
> what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing. I think I agree with this. > the difficulty people have with it is that it’s functional, not that it’s nix. No I don't think that's the problem people have with it. Speaking for myself the thing that's hard about Nix is first and foremost the bad error messages and secondly the complexity of idioms used in nixpkgs. If you stray just a little bit from the happy path, you're liable to get a ton of very arcane problems, and the error message often has nothing to do with the actual problem because a lot of the idioms used in nixpkgs end up doing clever things with Nix that work well when everything lines up just right, but blow up when just a little bit is wrong. The functional parts of Nix can be obstacles for someone new to functional programming, but when something goes wrong the developer has a clear sense of what is wrong ("ugh why is this immutable?!") even if it's not clear how to fix it. The sheer complexity of nixpkgs though can cause breakages in ways that don't make it clear at all what went wrong. There are a variety of ways that this could be fixed either in concert with changes to the language itself, or whole-scale changes to the interpreter/compiler.
- n42 5y ago
  you’re right. I guess I should qualify that with: what makes the language more difficult to approach as a newcomer. once you’re in there, there’s a ton of warts, of course. I just hear complaints about the syntax so much that it really seems like people are more caught up learning functional programming than Nix. which makes sense, since most people who would need Nix spend their time writing Bash and Python
  - dwohnitmok 5y ago
    I think the problem is that the bad error messages make it unclear whether something is a syntax issue or a nixpkgs issue (this is somewhat worse with the dynamic nature of Nix, although I personally don't actually think Nix really needs static typing all that much, but that would be one viable way of fixing this).
- freeopinion 5y ago
  In that case, what if you swapped out the language for, say, Scheme? Does that help?
  - Ericson2314 5y ago
    There is Guile for that. The Nix language out-schemes scheme (even smaller), so I don't really see the point.
    - mbrock 5y ago
      One reason is that Scheme has Emacs modes that connect to a live system for precise jump-to-definition, etc. This works with Guix and is extremely convenient. Scheme's metaprogramming also enables Guix's beautiful system of code staging, G-expressions. https://guix.gnu.org/manual/en/html_node/G_002dExpressions.html https://guix.gnu.org/manual/en/html_node/G_002dExpressions.h...
      - Ericson2314 5y ago
remexre 5y ago
idk, as a part-time Haskeller, I think Nix-the-language kinda sucks (tho not enough for me to not use nix). IMO the big huge thing is really inconsistent nixpkgs docs; compare linkFarm and symlinkJoin's docs, for example. I wish there were some way of getting nice autogenerated docs, but I don't think we're gonna get there without either adding some kind of type system or having a pretty strong review requirement that's actually enforced, and doing that for a year or more...
- octoberfranklin 5y ago
  Plus the nixpkgs and nixos docs are generated from some weird hybrid docbook-markdown that mere mortals (well me at least) can't get to build. So we are stuck using the makes-my-eyes-bleed font on nixos.org, and the gigantic mile-long single-page manual format (which is nice sometimes, like for searching, but other times you want a TOC sidebar). The documentation for the nix language is all done in mdbook, and is beautiful and easy to read. I wish the nixpkgs/nixos manuals were like that.
  - 1_player 5y ago
    > makes-my-eyes-bleed font on nixos.org AKA the curse of macOS designers that have that setting that makes all fonts a little bolder, so they think 300 weight is perfectly acceptable for a documentation site, while everybody else have to strain their eyes to read too thin a black font on eye watering white for hours. Just go on nixos.org, remove the font-weight: 300 and see how much readable it is.
tikhonj 5y ago
> the difficulty people have with it is that it’s functional, not that it’s nix. My experience is that the difficulty people have is with Nixpkgs as a library/codebase rather than the language itself. Poor error message, unclear abstractions, lots of things managed through implicit conventions rather than in the language itself... it's a massive legacy codebase with a lot of internal inconsistency and some questionable practices. I'm convinced that if you had a magic codebase-cleaning wand and kept literally everything else about Nix (the language, the model, derivations) the same, you'd fix like 90% of the problems people have with the system.
hamandcheese 5y ago
> the difficulty people have with it is that it’s functional, not that it’s nix. I write plenty of functional scala. I still find nix to be rather impenetrable, largely due to its dynamic nature and unfamiliar syntax.
- n42 5y ago
  maybe that’s it; maybe it kind of sits in the middle where it tries to please everyone and ends up pleasing no one. not a great functional language, but functional enough to confuse you if you’ve never done functional and are expecting JSON.
  - carlmr 5y ago
    I've written this before. The issue is not because it's functional at all. That's a proximate explanation that's just plain false. Everyone I know that has tried Nix was a functional programmer first. Nobody had a good experience with Nix though. If I could describe my issues with Nix it's that: 1. The syntax is odd. It's usually better not to stray too far from common programming languages if you want your language to be accepted. 2. You often find two examples which work individually, but they use a different way to do things, so it's hard to get them to work together in the same configuration. 3. A lot of examples depend on some specific functions, which are hardly explained at all. There seem to be a lot of these special functions that make it very hard to make a mental model you can work from. 4. The error messages are worse than C++ templating errors. 5. At least last I checked the documentation was really lengthy, but never gave a good overview of the language, only gave some inconsistent examples instead. In the end you don't feel like you learned something.
qbasic_forever 5y ago
It's a higher level issue, declarative vs. programmatic environment control. It isn't that sysadmins don't understand programming, functional programming, etc.--everyone is devops these days. It's that in the world of system administration we've gone through many waves and trends with significant backlash against complete programmatic definition of environments. In the old days you'd exec a pile of shell scripts to go out and put your servers into the state you wanted. It was brittle, painful to understand, etc. Then things evolved into declarative definition of environments with tools like ansible. Now you just define the state of the world you want and ansible or other tools do the work to get the world into that state. This has evolved even further into declarative definition of entire distributed systems with kubernetes--you write out a pile of YAML that defines the state you want and kubetl and k8s controllers take care of making it happen. So there are definitely people that understand the value of functional programming, but don't want it to define their environments. I don't want to have to grok someone's 'clever' solutions to figure out that ultimately they just want package x, y, z and software foo installed. I just want to list what I want and let the tooling make it happen.
- dnr 5y ago
  > I just want to list what I want and let the tooling make it happen. That's just what Nix does? It's very much more declarative than any system I've seen. Yes, k8s turns your declarative manifest into running processes, but how was the image built? There's a huge gap there: you refer to container images by name, not by a description of the software you want them to contain, and then hope that some other process has built the image correctly. Nix can close that gap and take declarative all the way from the service manifest down to the git commit of the compiler used to build your binary.
  - rgoulter 5y ago
    The comment you're replying to describes concerns about maintenance burden from the programmatic nature of Nix. I think "declared in YAML, pointing to a Docker image", and "declared in Nix, pointing to some more Nix elsewhere in the codebase" is relatively moot to this point. (If you wrote the image, you'll know what it's expected to do; if you don't know the Nix you're pointing to, it's as opaque as a Docker image). Configuring with a program vs using a plain structured file have different trade-offs.
rgoulter 5y ago
> the language itself is surprisingly simple. the difficulty people have with it is that it’s functional, not that it’s nix. I wrote down "what I wish I knew when learning Nix", and realised what had initially confused me: Some people are confused by immutability when learning functional programming. e.g. Programs involve changing things, but then immutable stuff doesn't change. With Nix, packages get built and installed to the store. In other solutions, this is done by running a command like "install package", or by having some file describing the package and running "install this"... but with Nix, packages are so integral to the language that they're built as part of just evaluating the language expressions, and (before flakes) the language didn't really have a "main file format" the same way that programming languages do, or that Terraform does. With functional programming, pure functions have no side effects. With Nix, an implicit side effect of evaluating code is that packages are built.
- tadfisher 5y ago
  Sort of. There are no real side effects, just lazy evaluation. Every entry point into `nix build` evaluates one expression to produce one output, but in the process, ends up evaluating the outputs of all the dependent expressions as well. The Nix store essentially caches the results of these evaluations, which looks very much like a traditional package manager "installing" packages to the file system.
  - aij 5y ago
    It's kind of like how an implicit side effect in "normal" FP languages is that memory is being allocated. The nix garbage collector will even free up disk space by deleting unreferenced packages just like a garbage collector freeing memory by deleting unreferenced values.
octoberfranklin 5y ago
A bigger problem is that the command-line utilities (what git calls "porcelain") are full of jillions of inconsistencies. Some tools (nix-env) read ~/.nix-defexpr, others (nix-store) ignore it. Sometimes arguments are interpreted as filenames, sometimes as attrnames, and other times as a search query that nix will use to grind through some big list of package names. The new "nix" command with subcommands ("nix env" instead of "nix-env") is much better, but has been stuck in "experimental status, breaking changes may occur at any time". Stabilizing the nix command syntax and deprecating nix-env/nix-store/nix-instantiate would go a long way.
jfb 5y ago
The problem is that the documentation is garbage.
viraptor 5y ago
> the difficulty people have with it is that it’s functional, not that it’s nix Not really - functional languages are ok. The problems I have are nix-specific: - for documentation you need to read the source - there's no debugger - there are no sanity-checks in the system which means that some internal function deep down the stack says "attribute never_heard_about_it missing" and you have no context how it got there - there's no type checking which results in the previous error on attribute foobar while you set attribute fobar and have no idea why things aren't working (or set {system}.{package} instead of {package}.{system})
PoignardAzur 5y ago
> I don’t want to be dismissive. “nix but with yaml” is kind of like saying “rust but without borrow checking”. I mean... your metaphor cuts both ways? A lot of work went into making Rust's borrow-checking non-intrusive, or at least softening its edges. The big improvements were lifetime elision and non-lexical lifetimes, but there's also a ton of compiler errors for common cases that explain what went wrong, and often suggest an easy fix when there is one. Last time I checked, Nix didn't really have this. If you get the syntax wrong, it doesn't tell you "oh, you tried to get 'ripgrep', you probably meant 'nixpkgs.ripgrep'".
- xyzzy_plugh 5y ago
  > Last time I checked, Nix didn't really have this. If you get the syntax wrong, it doesn't tell you "oh, you tried to get 'ripgrep', you probably meant 'nixpkgs.ripgrep'". I get where you're coming from but as it stands there is no universal description of what "nixpkgs" means in this context. It's a channel, defined only in the context of your environment. Your nixpkgs isn't my nixpkgs. It's just a channel label. Imagine you typed curl "PoignardAzur" compared with entering the same value into your browser's address bar. Would you expect to end up on your HN profile page in either case?
  - PoignardAzur 5y ago
    ... Okay? You're basically telling me "there's fundamental reasons Nix has these properties that make it annoying to use". And, okay, I believe you, but the end result is I don't want to bother.
    - xyzzy_plugh 5y ago
      I think what you're missing is that instead of providing the convenience behavior you're looking for, a more powerful primitive is available. Any other package manager has a bloated song and dance where if you want to install something not in the official repo, you either: - download and install it manually - add a new third-party repository and install it from there. Then, whenever you perform a distro upgrade, you have to repeat the entire process because the repo has changed, subtly. Instead, nix eschews this concept by allowing you to install whatever you want. Imagine running Ubuntu 18.04 and wanting to install a package from Ubuntu 20.10. Have fun with that! Nix not only makes it possible, it makes it as easy as installing anything else. I now consider "foo install ripgrep" a mistake and an anti-pattern. I now find those tools annoying to use. Could nix be better? Certainly, but you're really giving me a "it's different so I hate it" vibe. Give it a chance.
arianvanp 5y ago
Funnily enough the author of nix kind of seems sad that they made nix a programming language and has been Experimenting with a TOML frontend. And also been Experimenting with a new more specified language called Nickel

by n42 5y ago

temptemptemp111 5y ago

dwohnitmok 5y ago

> what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing. I think I agree with this. > the difficulty people have with it is that it’s functional, not that it’s nix. No I don't think that's the problem people have with it. Speaking for myself the thing that's hard about Nix is first and foremost the bad error messages and secondly the complexity of idioms used in nixpkgs. If you stray just a little bit from the happy path, you're liable to get a ton of very arcane problems, and the error message often has nothing to do with the actual problem because a lot of the idioms used in nixpkgs end up doing clever things with Nix that work well when everything lines up just right, but blow up when just a little bit is wrong. The functional parts of Nix can be obstacles for someone new to functional programming, but when something goes wrong the developer has a clear sense of what is wrong ("ugh why is this immutable?!") even if it's not clear how to fix it. The sheer complexity of nixpkgs though can cause breakages in ways that don't make it clear at all what went wrong. There are a variety of ways that this could be fixed either in concert with changes to the language itself, or whole-scale changes to the interpreter/compiler.

n42 5y ago
you’re right. I guess I should qualify that with: what makes the language more difficult to approach as a newcomer. once you’re in there, there’s a ton of warts, of course. I just hear complaints about the syntax so much that it really seems like people are more caught up learning functional programming than Nix. which makes sense, since most people who would need Nix spend their time writing Bash and Python
- dwohnitmok 5y ago
  I think the problem is that the bad error messages make it unclear whether something is a syntax issue or a nixpkgs issue (this is somewhat worse with the dynamic nature of Nix, although I personally don't actually think Nix really needs static typing all that much, but that would be one viable way of fixing this).
freeopinion 5y ago
In that case, what if you swapped out the language for, say, Scheme? Does that help?
- Ericson2314 5y ago
  There is Guile for that. The Nix language out-schemes scheme (even smaller), so I don't really see the point.
  - mbrock 5y ago
    One reason is that Scheme has Emacs modes that connect to a live system for precise jump-to-definition, etc. This works with Guix and is extremely convenient. Scheme's metaprogramming also enables Guix's beautiful system of code staging, G-expressions. https://guix.gnu.org/manual/en/html_node/G_002dExpressions.html https://guix.gnu.org/manual/en/html_node/G_002dExpressions.h...
    - Ericson2314 5y ago

remexre 5y ago

idk, as a part-time Haskeller, I think Nix-the-language kinda sucks (tho not enough for me to not use nix). IMO the big huge thing is really inconsistent nixpkgs docs; compare linkFarm and symlinkJoin's docs, for example. I wish there were some way of getting nice autogenerated docs, but I don't think we're gonna get there without either adding some kind of type system or having a pretty strong review requirement that's actually enforced, and doing that for a year or more...

octoberfranklin 5y ago
Plus the nixpkgs and nixos docs are generated from some weird hybrid docbook-markdown that mere mortals (well me at least) can't get to build. So we are stuck using the makes-my-eyes-bleed font on nixos.org, and the gigantic mile-long single-page manual format (which is nice sometimes, like for searching, but other times you want a TOC sidebar). The documentation for the nix language is all done in mdbook, and is beautiful and easy to read. I wish the nixpkgs/nixos manuals were like that.
- 1_player 5y ago
  > makes-my-eyes-bleed font on nixos.org AKA the curse of macOS designers that have that setting that makes all fonts a little bolder, so they think 300 weight is perfectly acceptable for a documentation site, while everybody else have to strain their eyes to read too thin a black font on eye watering white for hours. Just go on nixos.org, remove the font-weight: 300 and see how much readable it is.

tikhonj 5y ago

> the difficulty people have with it is that it’s functional, not that it’s nix. My experience is that the difficulty people have is with Nixpkgs as a library/codebase rather than the language itself. Poor error message, unclear abstractions, lots of things managed through implicit conventions rather than in the language itself... it's a massive legacy codebase with a lot of internal inconsistency and some questionable practices. I'm convinced that if you had a magic codebase-cleaning wand and kept literally everything else about Nix (the language, the model, derivations) the same, you'd fix like 90% of the problems people have with the system.

hamandcheese 5y ago

> the difficulty people have with it is that it’s functional, not that it’s nix. I write plenty of functional scala. I still find nix to be rather impenetrable, largely due to its dynamic nature and unfamiliar syntax.

n42 5y ago
maybe that’s it; maybe it kind of sits in the middle where it tries to please everyone and ends up pleasing no one. not a great functional language, but functional enough to confuse you if you’ve never done functional and are expecting JSON.
- carlmr 5y ago
  I've written this before. The issue is not because it's functional at all. That's a proximate explanation that's just plain false. Everyone I know that has tried Nix was a functional programmer first. Nobody had a good experience with Nix though. If I could describe my issues with Nix it's that: 1. The syntax is odd. It's usually better not to stray too far from common programming languages if you want your language to be accepted. 2. You often find two examples which work individually, but they use a different way to do things, so it's hard to get them to work together in the same configuration. 3. A lot of examples depend on some specific functions, which are hardly explained at all. There seem to be a lot of these special functions that make it very hard to make a mental model you can work from. 4. The error messages are worse than C++ templating errors. 5. At least last I checked the documentation was really lengthy, but never gave a good overview of the language, only gave some inconsistent examples instead. In the end you don't feel like you learned something.

qbasic_forever 5y ago

It's a higher level issue, declarative vs. programmatic environment control. It isn't that sysadmins don't understand programming, functional programming, etc.--everyone is devops these days. It's that in the world of system administration we've gone through many waves and trends with significant backlash against complete programmatic definition of environments. In the old days you'd exec a pile of shell scripts to go out and put your servers into the state you wanted. It was brittle, painful to understand, etc. Then things evolved into declarative definition of environments with tools like ansible. Now you just define the state of the world you want and ansible or other tools do the work to get the world into that state. This has evolved even further into declarative definition of entire distributed systems with kubernetes--you write out a pile of YAML that defines the state you want and kubetl and k8s controllers take care of making it happen. So there are definitely people that understand the value of functional programming, but don't want it to define their environments. I don't want to have to grok someone's 'clever' solutions to figure out that ultimately they just want package x, y, z and software foo installed. I just want to list what I want and let the tooling make it happen.

dnr 5y ago
> I just want to list what I want and let the tooling make it happen. That's just what Nix does? It's very much more declarative than any system I've seen. Yes, k8s turns your declarative manifest into running processes, but how was the image built? There's a huge gap there: you refer to container images by name, not by a description of the software you want them to contain, and then hope that some other process has built the image correctly. Nix can close that gap and take declarative all the way from the service manifest down to the git commit of the compiler used to build your binary.
- rgoulter 5y ago
  The comment you're replying to describes concerns about maintenance burden from the programmatic nature of Nix. I think "declared in YAML, pointing to a Docker image", and "declared in Nix, pointing to some more Nix elsewhere in the codebase" is relatively moot to this point. (If you wrote the image, you'll know what it's expected to do; if you don't know the Nix you're pointing to, it's as opaque as a Docker image). Configuring with a program vs using a plain structured file have different trade-offs.

rgoulter 5y ago

> the language itself is surprisingly simple. the difficulty people have with it is that it’s functional, not that it’s nix. I wrote down "what I wish I knew when learning Nix", and realised what had initially confused me: Some people are confused by immutability when learning functional programming. e.g. Programs involve changing things, but then immutable stuff doesn't change. With Nix, packages get built and installed to the store. In other solutions, this is done by running a command like "install package", or by having some file describing the package and running "install this"... but with Nix, packages are so integral to the language that they're built as part of just evaluating the language expressions, and (before flakes) the language didn't really have a "main file format" the same way that programming languages do, or that Terraform does. With functional programming, pure functions have no side effects. With Nix, an implicit side effect of evaluating code is that packages are built.

tadfisher 5y ago
Sort of. There are no real side effects, just lazy evaluation. Every entry point into `nix build` evaluates one expression to produce one output, but in the process, ends up evaluating the outputs of all the dependent expressions as well. The Nix store essentially caches the results of these evaluations, which looks very much like a traditional package manager "installing" packages to the file system.
- aij 5y ago
  It's kind of like how an implicit side effect in "normal" FP languages is that memory is being allocated. The nix garbage collector will even free up disk space by deleting unreferenced packages just like a garbage collector freeing memory by deleting unreferenced values.

octoberfranklin 5y ago

A bigger problem is that the command-line utilities (what git calls "porcelain") are full of jillions of inconsistencies. Some tools (nix-env) read ~/.nix-defexpr, others (nix-store) ignore it. Sometimes arguments are interpreted as filenames, sometimes as attrnames, and other times as a search query that nix will use to grind through some big list of package names. The new "nix" command with subcommands ("nix env" instead of "nix-env") is much better, but has been stuck in "experimental status, breaking changes may occur at any time". Stabilizing the nix command syntax and deprecating nix-env/nix-store/nix-instantiate would go a long way.

jfb 5y ago

The problem is that the documentation is garbage.

viraptor 5y ago

> the difficulty people have with it is that it’s functional, not that it’s nix Not really - functional languages are ok. The problems I have are nix-specific: - for documentation you need to read the source - there's no debugger - there are no sanity-checks in the system which means that some internal function deep down the stack says "attribute never_heard_about_it missing" and you have no context how it got there - there's no type checking which results in the previous error on attribute foobar while you set attribute fobar and have no idea why things aren't working (or set {system}.{package} instead of {package}.{system})

PoignardAzur 5y ago

> I don’t want to be dismissive. “nix but with yaml” is kind of like saying “rust but without borrow checking”. I mean... your metaphor cuts both ways? A lot of work went into making Rust's borrow-checking non-intrusive, or at least softening its edges. The big improvements were lifetime elision and non-lexical lifetimes, but there's also a ton of compiler errors for common cases that explain what went wrong, and often suggest an easy fix when there is one. Last time I checked, Nix didn't really have this. If you get the syntax wrong, it doesn't tell you "oh, you tried to get 'ripgrep', you probably meant 'nixpkgs.ripgrep'".

xyzzy_plugh 5y ago
> Last time I checked, Nix didn't really have this. If you get the syntax wrong, it doesn't tell you "oh, you tried to get 'ripgrep', you probably meant 'nixpkgs.ripgrep'". I get where you're coming from but as it stands there is no universal description of what "nixpkgs" means in this context. It's a channel, defined only in the context of your environment. Your nixpkgs isn't my nixpkgs. It's just a channel label. Imagine you typed curl "PoignardAzur" compared with entering the same value into your browser's address bar. Would you expect to end up on your HN profile page in either case?
- PoignardAzur 5y ago
  ... Okay? You're basically telling me "there's fundamental reasons Nix has these properties that make it annoying to use". And, okay, I believe you, but the end result is I don't want to bother.
  - xyzzy_plugh 5y ago
    I think what you're missing is that instead of providing the convenience behavior you're looking for, a more powerful primitive is available. Any other package manager has a bloated song and dance where if you want to install something not in the official repo, you either: - download and install it manually - add a new third-party repository and install it from there. Then, whenever you perform a distro upgrade, you have to repeat the entire process because the repo has changed, subtly. Instead, nix eschews this concept by allowing you to install whatever you want. Imagine running Ubuntu 18.04 and wanting to install a package from Ubuntu 20.10. Have fun with that! Nix not only makes it possible, it makes it as easy as installing anything else. I now consider "foo install ripgrep" a mistake and an anti-pattern. I now find those tools annoying to use. Could nix be better? Certainly, but you're really giving me a "it's different so I hate it" vibe. Give it a chance.

arianvanp 5y ago

Funnily enough the author of nix kind of seems sad that they made nix a programming language and has been Experimenting with a TOML frontend. And also been Experimenting with a new more specified language called Nickel