4 ms·

Fix the learning curve. I love Nix and NixOS and have used them for years, but it always feels like I am stuck in beginner level when it comes to understanding

by ixxie 4y ago

Fix the learning curve. I love Nix and NixOS and have used them for years, but it always feels like I am stuck in beginner level when it comes to understanding the language. The biggest obstacle is pedagogic. I think big wins can be make by creating an up-to-date, deep-dive learning resource. I get the suspicion that one must learn Nix in a somewhat different way than one learns other languages. But I don't know what this method should be, and I wish somebody showed it to me. Admittedly, some of the difficulty relates to the Nix language itself. I got excited when I saw a gist [1] by Eelco Dolstra that 'naturalize' aspects of the Nix language by bringing them down a level of abstraction. I am disappointed this isn't discussed so often in the community. Making configurations and packages explicit parts of the language - as Eelco suggests - is certainly going to help us mere-mortals understand what is going on in Nix. But syntactic improvements that makes Nix feel more like YAML are also huge: familiarity is a cornerstone of intuitiveness. Please twaeg - make this happen! [1] https://gist.github.com/edolstra/29ce9d8ea399b703a7023073b0dbc00d https://gist.github.com/edolstra/29ce9d8ea399b703a7023073b0d...

mboes 4y ago
We're onto the pedagogy thing. Check out the Nix book efforts: https://discourse.nixos.org/t/documentation-team-flattening-the-learning-curve/20003 https://discourse.nixos.org/t/documentation-team-flattening-.... Regarding the language and "configurations" specifically, you might like what we do with Nickel: https://github.com/tweag/nickel https://github.com/tweag/nickel. Research project showing a potential future for Nix.
ghuntley 4y ago
See https://nix.dev https://nix.dev
crabbygrabby 4y ago
I'm not so sure making nix comprehensible is realistic. When technologies fall under this level of complexity they require die hard fans to use it and keep it alive In all honesty, I would consider a complete rewrite at this point. I don't think there's a lot of hope for nix right now outside of hobbyists and researchers. Not saying this to be rude, but genuinely, take what you all have learned, take a sober look at the state of it, improve it. Almost no one will be willing to cope with it in it's current state docs or not. If it was the next docker/podman/etc you'd of known by now... It's not getting there, revert course
- otabdeveloper4 4y ago
  > outside of hobbyists and researchers No data on this, but I'm pretty sure Nix is used mostly by for-profit companies trying to tame complexity on a limited budget. It's not nice or pretty, but there's very little alternative unless you're ready to keep a whole team of developers just fixing Dockerfiles all day.
  - crabbygrabby 4y ago
    I've used it in industry and it was nothing short of a disaster. Only one person could fix builds, despite many genuinely brilliant engineers putting in hours to learn it. More so, the time sink... Literally, what takes 29 minutes for a fresher to do in docker takes them two weeks with nothing to show for it in nix. Absolutely do not recommend it for industry whatsoever. Most people, except the one advocate for it, see it as a failed experiment.
    - otabdeveloper4 4y ago
      If you work in a place where you have teams (multiple) of developers doing Docker crap, then nix is probably not for you. To each his own, it targets an entirely different niche.
- WickedSmoke 4y ago
  Recently someone has been trying to build a Nix package of an open source game I maintain, so I had a brief look at the project. It does appear to be an experiment in package management that got out of hand. Basic usability is lacking, as I was unable to even get a listing of available packages on a NixOS virtual machine due to nix-env requiring well over 1GB of RAM. This flagrant waste of resources doesn't inspire confidence in the quality of the tools. I'd rather see existing packaging data leveraged rather than adding a new language to the mix. Something like a translator or interpreter for RPM .spec files, for example.
  - jbboehr 4y ago
    Listing all packages is a bit of a weak spot. The entire package set is described in a lazy, functional language and listing or searching it requires evaluating the entire thing. A normal build will only require evaluating a small subset of the entire package list. `nix search` should have caching of results but it still requires evaluation to be populated.
shashurup 4y ago
Interesting. I don't find the Nix language itself especially complex, however, the whole system built with it is not that easy. For instance, packaging process is very well documented, making a derivation looked simple and reasonable until I decided package some code for myself. At this point things stopped being smooth. According to the documentation I needed to explicitly import my nix file from the top-level list of all packages which was not what I wanted, I'm unsure anybody except me would want my package (at least at the early stage of development). Intuitively, I was sure it wasn't necessary, there definitely must be a simpler way to toy with packaging but skimming through the documentation didn't reveal any answer. Looking at the source code left the impression that I needed a lot more time to understand how things worked behind the hood. On the other hand replacing pyenv with Nix was very pleasant experience. Overriding an existing package with my fork on github was almost a one-liner.
- runeks 4y ago
  > According to the documentation I needed to explicitly import my nix file from the top-level list of all packages […] Can you elaborate on this? I don’t follow.
  - pxc 4y ago
    The Nixpkgs packaging guide describes how to use the Nixpkgs packaging tools in the context of contributing to Nixpkgs, where to populate the package set with your custom packages, you add them on a top-level attribute in pkgs/top-level/default.nix. But a lot of users want to leverage Nixpkgs while instead (or simply first) adding their custom packages to an overlay or a company repo of Nix packages.
  - shashurup 4y ago
    From the [1]: > 3. Add the package to the file pkgs/top-level/all-packages.nix. The Nix expression written in the first step is a function; it requires other packages in order to build it. In this step you put it all together, i.e., you call the function with the right arguments to build the actual package. [1] https://nixos.org/manual/nix/stable/expressions/simple-expression.html https://nixos.org/manual/nix/stable/expressions/simple-expre...

by ixxie 4y ago

mboes 4y ago

We're onto the pedagogy thing. Check out the Nix book efforts: https://discourse.nixos.org/t/documentation-team-flattening-the-learning-curve/20003 https://discourse.nixos.org/t/documentation-team-flattening-.... Regarding the language and "configurations" specifically, you might like what we do with Nickel: https://github.com/tweag/nickel https://github.com/tweag/nickel. Research project showing a potential future for Nix.

ghuntley 4y ago

See https://nix.dev https://nix.dev

crabbygrabby 4y ago

I'm not so sure making nix comprehensible is realistic. When technologies fall under this level of complexity they require die hard fans to use it and keep it alive In all honesty, I would consider a complete rewrite at this point. I don't think there's a lot of hope for nix right now outside of hobbyists and researchers. Not saying this to be rude, but genuinely, take what you all have learned, take a sober look at the state of it, improve it. Almost no one will be willing to cope with it in it's current state docs or not. If it was the next docker/podman/etc you'd of known by now... It's not getting there, revert course

otabdeveloper4 4y ago
> outside of hobbyists and researchers No data on this, but I'm pretty sure Nix is used mostly by for-profit companies trying to tame complexity on a limited budget. It's not nice or pretty, but there's very little alternative unless you're ready to keep a whole team of developers just fixing Dockerfiles all day.
- crabbygrabby 4y ago
  I've used it in industry and it was nothing short of a disaster. Only one person could fix builds, despite many genuinely brilliant engineers putting in hours to learn it. More so, the time sink... Literally, what takes 29 minutes for a fresher to do in docker takes them two weeks with nothing to show for it in nix. Absolutely do not recommend it for industry whatsoever. Most people, except the one advocate for it, see it as a failed experiment.
  - otabdeveloper4 4y ago
    If you work in a place where you have teams (multiple) of developers doing Docker crap, then nix is probably not for you. To each his own, it targets an entirely different niche.
WickedSmoke 4y ago
Recently someone has been trying to build a Nix package of an open source game I maintain, so I had a brief look at the project. It does appear to be an experiment in package management that got out of hand. Basic usability is lacking, as I was unable to even get a listing of available packages on a NixOS virtual machine due to nix-env requiring well over 1GB of RAM. This flagrant waste of resources doesn't inspire confidence in the quality of the tools. I'd rather see existing packaging data leveraged rather than adding a new language to the mix. Something like a translator or interpreter for RPM .spec files, for example.
- jbboehr 4y ago
  Listing all packages is a bit of a weak spot. The entire package set is described in a lazy, functional language and listing or searching it requires evaluating the entire thing. A normal build will only require evaluating a small subset of the entire package list. `nix search` should have caching of results but it still requires evaluation to be populated.

shashurup 4y ago

Interesting. I don't find the Nix language itself especially complex, however, the whole system built with it is not that easy. For instance, packaging process is very well documented, making a derivation looked simple and reasonable until I decided package some code for myself. At this point things stopped being smooth. According to the documentation I needed to explicitly import my nix file from the top-level list of all packages which was not what I wanted, I'm unsure anybody except me would want my package (at least at the early stage of development). Intuitively, I was sure it wasn't necessary, there definitely must be a simpler way to toy with packaging but skimming through the documentation didn't reveal any answer. Looking at the source code left the impression that I needed a lot more time to understand how things worked behind the hood. On the other hand replacing pyenv with Nix was very pleasant experience. Overriding an existing package with my fork on github was almost a one-liner.

runeks 4y ago
> According to the documentation I needed to explicitly import my nix file from the top-level list of all packages […] Can you elaborate on this? I don’t follow.
- pxc 4y ago
  The Nixpkgs packaging guide describes how to use the Nixpkgs packaging tools in the context of contributing to Nixpkgs, where to populate the package set with your custom packages, you add them on a top-level attribute in pkgs/top-level/default.nix. But a lot of users want to leverage Nixpkgs while instead (or simply first) adding their custom packages to an overlay or a company repo of Nix packages.
- shashurup 4y ago
  From the [1]: > 3. Add the package to the file pkgs/top-level/all-packages.nix. The Nix expression written in the first step is a function; it requires other packages in order to build it. In this step you put it all together, i.e., you call the function with the right arguments to build the actual package. [1] https://nixos.org/manual/nix/stable/expressions/simple-expression.html https://nixos.org/manual/nix/stable/expressions/simple-expre...