11 ms·

"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn

"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". Maybe that is difficult for people who haven't had an experience with pure/functional programming? Though, yes, the way Nix is used can be quite complicated/sophisticated. -- Even if all of Nixpkgs were translated to JavaScript, I think it'd still be complicated to understand. (Though I suspect using a more general purpose language would allow for more footguns). +1 to the sentiment that most of the time you can get by just fine, but when you can't, NixOS is more difficult to make progress with compared to other Linux distributions.

count 5y ago
We already had JSON plus functions. We called it 'JavaScript' :)
- jeofken 5y ago
  JavaScript also includes bad footgun-features like procedures, aka functions with effects. Neither Nix nor JSON have this feature, making Nix in this aspect closer to JSON than JavaScript is.
- gorjusborg 5y ago
  Ha, nice! Seriously though, javascript is not a great language if you are looking for robust determinism. I can understand their decision to go elsewhere, given the domain and design.
  - IshKebab 5y ago
    People have tried: https://github.com/jkcfg/jk https://github.com/jkcfg/jk But yeah I agree. The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts? Google had the same problem for Bazel, and their solution (Starlark) is way easier to understand.
    - gorjusborg 5y ago
      > The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts? Yeah, that's a good point. I don't see any reason determinism requires a functional paradigm. That said, the functional language communities probably value determinism more than the others, currently. Choosing a language whose community values align with your needs can be a good thing.
nvarsj 5y ago
For me, nix the language itself is not that bad. It's all the magic happening in nixpkgs and the tight coupling there with the user interface (configuration.nix, shell.nix, etc.). In NixOS/nix, you are essentially extending the nixpkgs source code with your own configuration to build a system, which requires good familiarity with the source. This would be like having to write C code to install packages on another OS. It's a questionable design choice but it does offer a lot of power.
TheYumasi 5y ago
> Maybe that is difficult for people who haven't had an experience with pure/functional programming? I found my understanding of the Nix language became a lot better once I started learning some Haskell. Specifically once I understood what currying was about. My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough.
- ghostwriter 5y ago
  > My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough. How hard have you tried? It's literally two clicks and one scroll away from the official home page: https://nixos.org/ https://nixos.org/ -> click "Learn" -> Scroll down -> click "Full Nix Manual": https://nixos.org/manual/nix/stable/expressions/builtins.html https://nixos.org/manual/nix/stable/expressions/builtins.htm...
  - rgoulter 5y ago
    Nix is wonderful, but absolutely is under-documented. (In part due to a small community, etc.). A couple of examples I've run into: https://github.com/NixOS/nix/issues/2259 https://github.com/NixOS/nix/issues/2259 showed people trying to make use of the "hello world" package which was given in the NixPkgs manual, but couldn't quite figure out how to get it to build. e.g. if you want a package that's a simple script, "writeScriptBin" seems like what you'd want. -- But it's really not clear how to use it from the manual; you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-writeText https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri...
    - ghostwriter 5y ago
      > you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri... Is it too much to ask from developers in 2022? At source, the function is well documented and is provided with an example [1]. The only missing part is a rendered HTML with the same information. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/trivial-builders.nix#L187-L199 https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...
otabdeveloper4 5y ago
> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". It's too simple and straightforward. Writing Nix expressions is a bit like writing Javascript without frameworks or libraries. Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)
- pcthrowaway 5y ago
  > Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.) Out of curiosity, are you talking about Typescript? Not really a framework, but I can't really think of a framework that 'won' in this sense for JS, and also compiles to JS. On the front-end there's Svelte, which is actually compiled with Javascript, and React, which is has the biggest market share of opinionated Javascript frameworks, but at best you could say JSX is compiled to HTML. On the back-end, there's express, but that doesn't involve any compilation, and is far from opinionated...
  - otabdeveloper4 5y ago
    Before Typescript there was also Coffeescript. Sic transit. :) But also things like Vue do their own compiling step too.
- mikepurvis 5y ago
  The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages. I don't agree with this direction, though. Basic packages can already be described pretty simply using native nixlang, and the complexity scales well— you can add patches, fixups, flags on dependencies, extra fetcher args, whatever and it's a pretty smooth ramp all the way up. Whereas it would be considerably more jarring if you could use the "simple" thing up until the point where you abruptly hit a wall and then suddenly had to start over in real Nix when you hit that one thing that happens to require it. Quite apart from that side of things, if a significant portion of nixpkgs were converted to the new simplified package definition style, it would majorly shrink the potential pool of example package definitions for novices to examine.
ashtonkem 5y ago
> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". Maybe that is difficult for people who haven't had an experience with pure/functional programming? I've programmed professionally in Lisp (SBCL) and Clojure, and done a lot of hobby work in Haskell and Rust. I found Nix the language utterly incomprehensible largely because of documentation and tooling reasons.
- ghostwriter 5y ago
  I've programmed professionally in Haskell, I find Nix the Language to be one of the nicest DSLs for defining build pipelines. It's lazy, pure, and it's sandboxed. Whenever you need types on top of it you just pick Dhall and dhall-nix and continue with a productivity gain.
  - kaba0 5y ago
    Wow, I just commented that dhall would probably be a fruitful language to consider for nix! And it seems to exist, though according to the readme, general recursion, not strongly typed code and row polymorphism is not supported by dhall but is used heavily by nix :/ Do you by chance know whether a non-Turing complete language like Dhall would be enough to “replace” nix?
    - ghostwriter 5y ago
      > Do you by chance know whether a non-Turing complete language like Dhall would be enough to “replace” nix? Realistically, I'd say Dhall should be viewed as a complimentary typed DSL for Nix instead "a replacement". Dhall shines when it's used as a code-generator for recursive Nix expressions from typed configs that capture the intent of a build pipeline. You can see how it can be generated from this Haskell example, for instance [1]. The [2] shows you the available constructs, that do support recursive calls and recursive Nix sets. [1] https://hackage.haskell.org/package/dhall-nix-1.1.23/docs/Dhall-Nix.html#g:1 https://hackage.haskell.org/package/dhall-nix-1.1.23/docs/Dh... [2] https://hackage.haskell.org/package/hnix-0.14.0.2/docs/Nix-Expr-Types.html#t:NExprF https://hackage.haskell.org/package/hnix-0.14.0.2/docs/Nix-E...
mindslight 5y ago
The semantics are simple and necessary, yes. The syntax is kind of crap in some ways (in others it's awesome and I wish other languages were as lightweight). Syntax in general is a bikeshed, but that doesn't mean we can't objectively critique things like having function definition being a mere ":". That one on its own is probably responsible for much of the indecipherability. Also some of the higher level constructs really aren't clear (like overrideDerivation/overrideAttrs/override, I still don't fully get). And mkDefault/mkForce/etc could be a bit more front and center rather than in "lib". Also every time I run nixos-rebuild and it takes several+ seconds to evaluate my Nix expression I've got to wonder how much the implementation being this cute functional fixpoint is holding performance back.
- rnhmjoj 5y ago
  > overrideDerivation/overrideAttrs/override, I still don't fully get Packages are implemented as functions that take dependencies as arguments, do some stuff and ultimately output the result of calling mkDerivation (i.e. a derivation). `override` allows you to change the arguments of the package, while `overrideAttrs` allows you to change the arguments of mkDerivation: the implementation of the package itself. `overrideDerivation` is essentially a deprecated `overrideAttrs` version. https://nixos.org/manual/nixpkgs/stable/#chap-overrides https://nixos.org/manual/nixpkgs/stable/#chap-overrides for a better explenation.
  - mindslight 5y ago
    Ah, I had forgotten `override` is easy. Rereading that page I still don't get the difference between `overrideAttrs` and `overrideDerivation`. `overrideAttrs` is newer and preferred, yet it doesn't spell out where you cannot use it and have to fall back to `overrideDeriviation`. And looking through my Nix code I've got various uses of `overrideDerivation`, which most likely means I tried `overrideAttrs` only to have it not work, so I tried the "deprecated" version and it did.
    - rnhmjoj 5y ago
      I think the manual is intetionally flying over `overrideDerivation` because it shouldn't be used. To understand the difference you'd have to know that `stdenv.mkDerivation` is a library function that wraps the Nix primitive `builtins.derivation`, which is what actually makes a derivation. `overrideAttrs` changes the arguments of the former, while `overrideDerivation` changes the arguments of the latter. The reason is it's "deprecated" is that it forces a full evaluation of `stdenv.mkDerivation` before it can continue and it override the lower-level derivation, so some niceties that Nixpkgs provides don't work with it.
jcranberry 5y ago
It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these special functions which as far as I can tell were undocumented and I couldn't figure out what they could do. So there was sort of this gap in terms of documentation between theoretical understanding and tooling/functional understanding which I struggled to cross.
- mplanchard 5y ago
  The best way I’ve found around this is to always keep a local clone of nixpkgs so that I can grep for where functions are defined and hope like hell that there are some comments in the vicinity. Definitely not ideal.
  - rgoulter 5y ago
    If you're using Nix on your system, you can also find nixpkgs symlinked under ~/.nix-defexpr/channels/nixpkgs/pkgs/ or so.
    - mplanchard 5y ago
      Nice, I did not know this. Thanks!
    - Filligree 5y ago
      And if you have flakes and nix-command enabled, you can run `nix edit nixpkgs#lib.sort` to get the definition of the sort function. (This will just tell you it's imported from lists. `nix edit nixpkgs#lib.lists.sort` will get you the actual definition.)
- snowytrees 5y ago
  100% this. The language is designed for its use case which is packaging and configuration (nothing more or less). It has a learning curve due to being lazy and functional but works great once you get the hang of it. But the documentation of all its functions is so annoying. You have builtins and the nixpkgs functions[1]. There is learning the language, and then learning how to use it. Then there is the entire ecosystem of custom packaging functions that have their own pros/cons [2]. The issue isn’t with the language but the difficulty with trying to make existing tooling work the Nix way. That part is where I agree with the curse of nix. But the effort is worth it because once the packaging is complete it just works (forever). 1: Best resource I’ve found is this: https://teu5us.github.io/nix-lib.html https://teu5us.github.io/nix-lib.html 2: The status of lang2nix: https://discourse.nixos.org/t/status-of-lang2nix-approaches/ https://discourse.nixos.org/t/status-of-lang2nix-approaches/...
JamesSwift 5y ago
I was definitely in the "I just dont get it" camp for a couple years before coming across a comment on HackerNews pointing to Burke Libbeys fantastic playlist on Nix [1]. It was a revelation and was what I needed to finally have the DSL click for me. Cant recommend it enough. [1] - https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...
- jerdfelt 5y ago
  Is there anything that explains the why and how a bit deeper? As an example, in the video "Packaging a Gem as a Nix derivation", he basically just and copies and pastes another default.nix, changes some strings and mentions he doesn't understand what 'passthrough.updateScript' does, but just changes a string there too. This doesn't really help me understand Nix.
  - JamesSwift 5y ago
    I would watch the entire thing in order to get the "full experience" of his tutorial. This touches on things like the CLI vs just syntax. If you are coming from the perspective of non-NixOS (e.g. HomeManager or just nixpkgs) then maybe start at his rundown of what NixOS is vs HomeManager [1]. Or if you really just want to understand the nix language itself then probably start at 'Demystifying nixpkgs' [2]. [1] - https://www.youtube.com/watch?v=IUsQt4NRCnc&list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs&index=8 https://www.youtube.com/watch?v=IUsQt4NRCnc&list=PLRGI9KQ3_H... [2] - https://www.youtube.com/watch?v=oWJaTb5uoT0&list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs&index=14 https://www.youtube.com/watch?v=oWJaTb5uoT0&list=PLRGI9KQ3_H...
octoberfranklin 5y ago
> the Nix language is about as straightforward as "JSON plus functions". Except that they concoct weird custom terminology for everything. It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight. It's not a build script, it's a derivation. Etc, etc.
- rgoulter 5y ago
  > It's not a build script, it's a derivation. I think this one's a fair example of a specific terminology, though? The idea of building a package in a certain way, and storing it in a certain way, is foundational to the Nix packaging system.
- jonringer117 5y ago
  > It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight. This was intentional. Most hashing algorithms don't guarantee a stable ordering of keys. Nix was inspired by a research project called Aterm, which did have this property. Also, you can do things like reference other keys in an attr set, which many other dictionary data structures don't support. > It's not a build script, it's a derivation. Derivation encapsulates everything which goes into a building something. Dependencies, env vars, flags, sources, patches, the build script, package version, and package name all get packed into a derivation. These paramaters get hashed which is how the hash for the store path gets determined. Derivations can be thought of an unambiguous build "recipe", which has already resolved based upon all configurable inputs (dependencies, build platform, host platform, target platform) . https://book.divnix.com/ch04-01-create-a-derivation.html#inspect-the-contents-of-a-derivation https://book.divnix.com/ch04-01-create-a-derivation.html#ins... Nix is optimized for creating reproducible builds.
  - epolanski 5y ago
    Isn't a stable ordering just an n-tuple of pairs? Or is it more like a hashmap you access in O(1)?
  - deleted 5y ago
    [deleted]
deleted 5y ago
[deleted]
kaba0 5y ago
Seeing that the nix language was influenced heavily by haskell, perhaps Dhall would be an interesting “port”/change for the project - it is a deliberately non-Turing complete configuration language with types (but heavy type inference) and functions. Because let’s be honest, types are user documentation as well, and the project would benefit greatly from the latter.
- kaba0 5y ago
  Can’t edit anymore but this more or less exists already: dhall-nix can convert from dhall to nix, but unfortunately not everything done in nixpkgs can be converted clearly into dhall (due to nixpkgs’s use of some non-strongly typed parts and general recursion)

count 5y ago

We already had JSON plus functions. We called it 'JavaScript' :)

jeofken 5y ago
JavaScript also includes bad footgun-features like procedures, aka functions with effects. Neither Nix nor JSON have this feature, making Nix in this aspect closer to JSON than JavaScript is.
gorjusborg 5y ago
Ha, nice! Seriously though, javascript is not a great language if you are looking for robust determinism. I can understand their decision to go elsewhere, given the domain and design.
- IshKebab 5y ago
  People have tried: https://github.com/jkcfg/jk https://github.com/jkcfg/jk But yeah I agree. The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts? Google had the same problem for Bazel, and their solution (Starlark) is way easier to understand.
  - gorjusborg 5y ago
    > The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts? Yeah, that's a good point. I don't see any reason determinism requires a functional paradigm. That said, the functional language communities probably value determinism more than the others, currently. Choosing a language whose community values align with your needs can be a good thing.

nvarsj 5y ago

For me, nix the language itself is not that bad. It's all the magic happening in nixpkgs and the tight coupling there with the user interface (configuration.nix, shell.nix, etc.). In NixOS/nix, you are essentially extending the nixpkgs source code with your own configuration to build a system, which requires good familiarity with the source. This would be like having to write C code to install packages on another OS. It's a questionable design choice but it does offer a lot of power.

TheYumasi 5y ago

> Maybe that is difficult for people who haven't had an experience with pure/functional programming? I found my understanding of the Nix language became a lot better once I started learning some Haskell. Specifically once I understood what currying was about. My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough.

ghostwriter 5y ago
> My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough. How hard have you tried? It's literally two clicks and one scroll away from the official home page: https://nixos.org/ https://nixos.org/ -> click "Learn" -> Scroll down -> click "Full Nix Manual": https://nixos.org/manual/nix/stable/expressions/builtins.html https://nixos.org/manual/nix/stable/expressions/builtins.htm...
- rgoulter 5y ago
  Nix is wonderful, but absolutely is under-documented. (In part due to a small community, etc.). A couple of examples I've run into: https://github.com/NixOS/nix/issues/2259 https://github.com/NixOS/nix/issues/2259 showed people trying to make use of the "hello world" package which was given in the NixPkgs manual, but couldn't quite figure out how to get it to build. e.g. if you want a package that's a simple script, "writeScriptBin" seems like what you'd want. -- But it's really not clear how to use it from the manual; you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-writeText https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri...
  - ghostwriter 5y ago
    > you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri... Is it too much to ask from developers in 2022? At source, the function is well documented and is provided with an example [1]. The only missing part is a rendered HTML with the same information. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/trivial-builders.nix#L187-L199 https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

otabdeveloper4 5y ago

> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". It's too simple and straightforward. Writing Nix expressions is a bit like writing Javascript without frameworks or libraries. Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)

pcthrowaway 5y ago
> Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.) Out of curiosity, are you talking about Typescript? Not really a framework, but I can't really think of a framework that 'won' in this sense for JS, and also compiles to JS. On the front-end there's Svelte, which is actually compiled with Javascript, and React, which is has the biggest market share of opinionated Javascript frameworks, but at best you could say JSX is compiled to HTML. On the back-end, there's express, but that doesn't involve any compilation, and is far from opinionated...
- otabdeveloper4 5y ago
  Before Typescript there was also Coffeescript. Sic transit. :) But also things like Vue do their own compiling step too.
mikepurvis 5y ago
The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages. I don't agree with this direction, though. Basic packages can already be described pretty simply using native nixlang, and the complexity scales well— you can add patches, fixups, flags on dependencies, extra fetcher args, whatever and it's a pretty smooth ramp all the way up. Whereas it would be considerably more jarring if you could use the "simple" thing up until the point where you abruptly hit a wall and then suddenly had to start over in real Nix when you hit that one thing that happens to require it. Quite apart from that side of things, if a significant portion of nixpkgs were converted to the new simplified package definition style, it would majorly shrink the potential pool of example package definitions for novices to examine.

ashtonkem 5y ago

> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". Maybe that is difficult for people who haven't had an experience with pure/functional programming? I've programmed professionally in Lisp (SBCL) and Clojure, and done a lot of hobby work in Haskell and Rust. I found Nix the language utterly incomprehensible largely because of documentation and tooling reasons.

ghostwriter 5y ago
I've programmed professionally in Haskell, I find Nix the Language to be one of the nicest DSLs for defining build pipelines. It's lazy, pure, and it's sandboxed. Whenever you need types on top of it you just pick Dhall and dhall-nix and continue with a productivity gain.
- kaba0 5y ago
  Wow, I just commented that dhall would probably be a fruitful language to consider for nix! And it seems to exist, though according to the readme, general recursion, not strongly typed code and row polymorphism is not supported by dhall but is used heavily by nix :/ Do you by chance know whether a non-Turing complete language like Dhall would be enough to “replace” nix?
  - ghostwriter 5y ago
    > Do you by chance know whether a non-Turing complete language like Dhall would be enough to “replace” nix? Realistically, I'd say Dhall should be viewed as a complimentary typed DSL for Nix instead "a replacement". Dhall shines when it's used as a code-generator for recursive Nix expressions from typed configs that capture the intent of a build pipeline. You can see how it can be generated from this Haskell example, for instance [1]. The [2] shows you the available constructs, that do support recursive calls and recursive Nix sets. [1] https://hackage.haskell.org/package/dhall-nix-1.1.23/docs/Dhall-Nix.html#g:1 https://hackage.haskell.org/package/dhall-nix-1.1.23/docs/Dh... [2] https://hackage.haskell.org/package/hnix-0.14.0.2/docs/Nix-Expr-Types.html#t:NExprF https://hackage.haskell.org/package/hnix-0.14.0.2/docs/Nix-E...

mindslight 5y ago

The semantics are simple and necessary, yes. The syntax is kind of crap in some ways (in others it's awesome and I wish other languages were as lightweight). Syntax in general is a bikeshed, but that doesn't mean we can't objectively critique things like having function definition being a mere ":". That one on its own is probably responsible for much of the indecipherability. Also some of the higher level constructs really aren't clear (like overrideDerivation/overrideAttrs/override, I still don't fully get). And mkDefault/mkForce/etc could be a bit more front and center rather than in "lib". Also every time I run nixos-rebuild and it takes several+ seconds to evaluate my Nix expression I've got to wonder how much the implementation being this cute functional fixpoint is holding performance back.

rnhmjoj 5y ago
> overrideDerivation/overrideAttrs/override, I still don't fully get Packages are implemented as functions that take dependencies as arguments, do some stuff and ultimately output the result of calling mkDerivation (i.e. a derivation). `override` allows you to change the arguments of the package, while `overrideAttrs` allows you to change the arguments of mkDerivation: the implementation of the package itself. `overrideDerivation` is essentially a deprecated `overrideAttrs` version. https://nixos.org/manual/nixpkgs/stable/#chap-overrides https://nixos.org/manual/nixpkgs/stable/#chap-overrides for a better explenation.
- mindslight 5y ago
  Ah, I had forgotten `override` is easy. Rereading that page I still don't get the difference between `overrideAttrs` and `overrideDerivation`. `overrideAttrs` is newer and preferred, yet it doesn't spell out where you cannot use it and have to fall back to `overrideDeriviation`. And looking through my Nix code I've got various uses of `overrideDerivation`, which most likely means I tried `overrideAttrs` only to have it not work, so I tried the "deprecated" version and it did.
  - rnhmjoj 5y ago
    I think the manual is intetionally flying over `overrideDerivation` because it shouldn't be used. To understand the difference you'd have to know that `stdenv.mkDerivation` is a library function that wraps the Nix primitive `builtins.derivation`, which is what actually makes a derivation. `overrideAttrs` changes the arguments of the former, while `overrideDerivation` changes the arguments of the latter. The reason is it's "deprecated" is that it forces a full evaluation of `stdenv.mkDerivation` before it can continue and it override the lower-level derivation, so some niceties that Nixpkgs provides don't work with it.

jcranberry 5y ago

It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these special functions which as far as I can tell were undocumented and I couldn't figure out what they could do. So there was sort of this gap in terms of documentation between theoretical understanding and tooling/functional understanding which I struggled to cross.

mplanchard 5y ago
The best way I’ve found around this is to always keep a local clone of nixpkgs so that I can grep for where functions are defined and hope like hell that there are some comments in the vicinity. Definitely not ideal.
- rgoulter 5y ago
  If you're using Nix on your system, you can also find nixpkgs symlinked under ~/.nix-defexpr/channels/nixpkgs/pkgs/ or so.
  - mplanchard 5y ago
    Nice, I did not know this. Thanks!
  - Filligree 5y ago
    And if you have flakes and nix-command enabled, you can run `nix edit nixpkgs#lib.sort` to get the definition of the sort function. (This will just tell you it's imported from lists. `nix edit nixpkgs#lib.lists.sort` will get you the actual definition.)
snowytrees 5y ago
100% this. The language is designed for its use case which is packaging and configuration (nothing more or less). It has a learning curve due to being lazy and functional but works great once you get the hang of it. But the documentation of all its functions is so annoying. You have builtins and the nixpkgs functions[1]. There is learning the language, and then learning how to use it. Then there is the entire ecosystem of custom packaging functions that have their own pros/cons [2]. The issue isn’t with the language but the difficulty with trying to make existing tooling work the Nix way. That part is where I agree with the curse of nix. But the effort is worth it because once the packaging is complete it just works (forever). 1: Best resource I’ve found is this: https://teu5us.github.io/nix-lib.html https://teu5us.github.io/nix-lib.html 2: The status of lang2nix: https://discourse.nixos.org/t/status-of-lang2nix-approaches/ https://discourse.nixos.org/t/status-of-lang2nix-approaches/...

JamesSwift 5y ago

I was definitely in the "I just dont get it" camp for a couple years before coming across a comment on HackerNews pointing to Burke Libbeys fantastic playlist on Nix [1]. It was a revelation and was what I needed to finally have the DSL click for me. Cant recommend it enough. [1] - https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...

jerdfelt 5y ago
Is there anything that explains the why and how a bit deeper? As an example, in the video "Packaging a Gem as a Nix derivation", he basically just and copies and pastes another default.nix, changes some strings and mentions he doesn't understand what 'passthrough.updateScript' does, but just changes a string there too. This doesn't really help me understand Nix.
- JamesSwift 5y ago
  I would watch the entire thing in order to get the "full experience" of his tutorial. This touches on things like the CLI vs just syntax. If you are coming from the perspective of non-NixOS (e.g. HomeManager or just nixpkgs) then maybe start at his rundown of what NixOS is vs HomeManager [1]. Or if you really just want to understand the nix language itself then probably start at 'Demystifying nixpkgs' [2]. [1] - https://www.youtube.com/watch?v=IUsQt4NRCnc&list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs&index=8 https://www.youtube.com/watch?v=IUsQt4NRCnc&list=PLRGI9KQ3_H... [2] - https://www.youtube.com/watch?v=oWJaTb5uoT0&list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs&index=14 https://www.youtube.com/watch?v=oWJaTb5uoT0&list=PLRGI9KQ3_H...

octoberfranklin 5y ago

> the Nix language is about as straightforward as "JSON plus functions". Except that they concoct weird custom terminology for everything. It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight. It's not a build script, it's a derivation. Etc, etc.

rgoulter 5y ago
> It's not a build script, it's a derivation. I think this one's a fair example of a specific terminology, though? The idea of building a package in a certain way, and storing it in a certain way, is foundational to the Nix packaging system.
jonringer117 5y ago
> It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight. This was intentional. Most hashing algorithms don't guarantee a stable ordering of keys. Nix was inspired by a research project called Aterm, which did have this property. Also, you can do things like reference other keys in an attr set, which many other dictionary data structures don't support. > It's not a build script, it's a derivation. Derivation encapsulates everything which goes into a building something. Dependencies, env vars, flags, sources, patches, the build script, package version, and package name all get packed into a derivation. These paramaters get hashed which is how the hash for the store path gets determined. Derivations can be thought of an unambiguous build "recipe", which has already resolved based upon all configurable inputs (dependencies, build platform, host platform, target platform) . https://book.divnix.com/ch04-01-create-a-derivation.html#inspect-the-contents-of-a-derivation https://book.divnix.com/ch04-01-create-a-derivation.html#ins... Nix is optimized for creating reproducible builds.
- epolanski 5y ago
  Isn't a stable ordering just an n-tuple of pairs? Or is it more like a hashmap you access in O(1)?
- deleted 5y ago
  [deleted]

deleted 5y ago

[deleted]

kaba0 5y ago

Seeing that the nix language was influenced heavily by haskell, perhaps Dhall would be an interesting “port”/change for the project - it is a deliberately non-Turing complete configuration language with types (but heavy type inference) and functions. Because let’s be honest, types are user documentation as well, and the project would benefit greatly from the latter.

kaba0 5y ago
Can’t edit anymore but this more or less exists already: dhall-nix can convert from dhall to nix, but unfortunately not everything done in nixpkgs can be converted clearly into dhall (due to nixpkgs’s use of some non-strongly typed parts and general recursion)