7 ms·

I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for

I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for the functions shown in the examples on the website to no avail. I searched packages, options, and even resorted to ctrl-f while clicking through the site "documentation"... It sounds awesome, but its in dire need of some better documentation if it wants to be accessible, IMHO. I simply didnt have the patience to delve any deeper.

domenkozar 6y ago
Did you follow the language tutorial in the manual or something else?
- supermatt 6y ago
  I would have followed the official manual. I see that you are putting together some tutorials, so I will definitely check those out.
throwaway894345 6y ago
I agree. I’ve spent person-weeks looking into Nix, and I still can’t get it to work beyond the most basic of use cases. A few weeks ago I spent an entire weekend on the Nix discord channel trying to get help to configure VSCode for Rust development, and we collectively couldn’t figure it out. Nix is a great idea, and it’s goals are ambitious, but I haven’t found it to be usable yet. Almost any time I try to do anything I get mired in a tar pit and I basically end up having to give up. I’ve learned lots of tools and technologies in my career, but Nix remains elusive.
- domenkozar 6y ago
  Do you have some examples of that? Maybe a link to discord discussion?
- pimeys 6y ago
  I did a month, diving directly into the deep end with flakes and all. I don't know, it really is hard in the beginning. Like, really hard. But eventually I got myself a setup I could use in my two laptops and workstation. A setup, that sets my home directory, all my programs and my custom desktop just the way I want. Everything is in the github repo, and installing with the flake will give me the exact experience I have in my other machines. I tend to use lots of custom tools and commands, that are really painful to install and setup for a new machine. With NixOS all of it is just one command away. But, I agree, it is REALLY HARD in the beginning to grasp things. Here's my configs if you want to see how I approached my own setup: https://github.com/pimeys/nixos https://github.com/pimeys/nixos
  - throwaway894345 6y ago
    "It's hard to grasp things" is only one part of the problem. I mentioned that there's no good way to understand nixpkgs except to manually traverse the file tree. Grokking the directory scheme will help a bit, but there's no amount of Nix Nirvana that will make it as easy as hovering over the parameter in VS Code. In other cases, things are just broken--my nix installed rustup is failing to build packages this morning with a clang linker error (can't find iconv) and Googling the error message + 'rust' indicates that this problem is only encountered in Nix environments. Similarly, many of the other problems are that it requires you to repackage other libraries from the ground up. For example, most Python packages are available in Pypi such that users can just `pip install` them. Nixpkgs has a `pypiPackage` function that allows us to import a package from Pypi, but if that package has C dependencies (and many do, because Python's performance sucks and Python's performance sucks because everything depends on C packages precluding optimizations to the interpreter, but that's a gripe for another day) then Nix requires you to package those C dependencies in Nix first, and because every C package has its own bespoke build system with implicit dependencies, you must be expert in each individual C package in the dependency tree. Again, there's no amount of Nix Nirvana that will save you from this. In many other cases (e.g., my 'packaging vs code with my rust plugins' example from my earlier post) we have to know the specific conventions for specific nixpkgs functions which will vary from others, and even that might not be enough. These conventions can't be derived from any general understanding or intuition of Nix (i.e., "Nix Nirvana") although it certainly doesn't hurt. Further, NixOS is easy mode. It's the first class citizen in the Nix ecosystem. Other platforms don't work so well. In my vs code + rust plugins example, there were several posts documenting the process on NixOS, but for whatever reason Nix on other platforms (e.g., macOS) requires different configuration which is undocumented and even proficient Nix users couldn't figure out the issue. But yeah, to your point, it is really hard to grasp as well, which exacerbates all of the above problems.
ivanbakel 6y ago
I am of a similar opinion, but I think it's largely due to my typical use case. If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing small invocations or on-the-fly editing, the docs are much less useful. There's also no way to understand it in terms of a few simple concepts for beginners. Do you want an override, an overlay, a flake, or something else? Does specifying an option in multiple places combine them, or does one spec override the other? It feels as though Nix is a technology of special cases, and the docs don't make it easy to understand what to do in each case when all you know is the kind of change you want to make. The worst culprit of this is NixOS services, which each declare an ad-hoc API that I normally find myself digging into the service declaration file in the Nix repo to try and understand.
- oblio 6y ago
  > If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing small invocations or on-the-fly editing, the docs are much less useful. This is super serious, major, I hope the devs are paying attention. Most users of anything are drive-by, rather casual users. Think of any big tech out there: they became popular precisely because they were easy to get started (at least back when they were launched/became popular): C, Unix, Bash, Perl, PHP, MySQL, Javascript, Java, Ruby, Go, etc. Almost everything that's big was usable by people don't read an entire book before they can make "Hello world".
  - Ericson2314 6y ago
    There are some serious gotchas like nix-env in this read I would like to delete. But, that said, I don't think targeting "drive by usesr" is worth it. The benefits of Nix is that it dramatically organizes the absolute disgusting mess that is how most people manage their computer. I don't want to drive people trying things out away, but Nix will never be worth it unless you embrace it, and half-ways usage will deliver all the downsides without enough of the upsides. Not every value function is monotonic like that, I am not going to pretend it's otherwise. The goal is to help people fully embrace it, not to allow them to comfortably come to a stand-still half way.
georgyo 6y ago
Having used nix for two years now for both work and personal purposes, I agree. Though I have also come to think nix is doing things in much better ways than AppImage, Docker, Snap, Flatpack, and others. I won't focus on the good parts, but focus on your comment. Nix has three things that I think are confusing and took me an embarrassing long time to grok, and I find other people confused by as well. 1. Where does the semicolon go? Reading code makes it feel arbitrary, but really the only time a semicolon is used is to terminate an assignment (=). If there are no equal signs, then you don't need any semicolons. 2. The heredoc strings ('' '') are in fact strings. Nixpkgs passes these strings to a shell quite frequently and their docs also make it feel like these statements are shell scripts and not strings. The problem here is that to pull a variable from nix you use ${VAR} and to use an environment variable you use $VAR. When you look at these heredocs it looks like a pure bash script, but it doesn't quickly jump out at you that ${VAR} are being templated in by nix. It also isn't obvious that $VAR is not being templated in by nix. 3. The nix language is very very tiny, and almost everything comes from nixpkgs which is basically stdlib as well as the package repository. Almost everything, including callPackage is in nixpkgs. The documentation is fairly decent, but when trying to figure out how do something, you are basically hunting in that code base. Bonus 4. In nix it is really easy to build single language applications. However if you need to mix two, finding good docs or examples is really hard. IE, if you want to build the javascript front end of your web app as well as the python backend. These combinations need at least two derivations, and how to make it happen is bespoke every time.
- siraben 6y ago
  Regular Nix user here, I agree with your points regarding the language's peculiarities, and adding on a few points: > 1. Where does the semicolon go? Reading code makes it feel arbitrary, but really the only time a semicolon is used is to terminate an assignment (=). If there are no equal signs, then you don't need any semicolons. The semicolon is also required when using with expressions (i.e. augments the environment of an expression like let, but confusingly doesn't shadow let bindings) nix-repl> with { a = 3; }; a 3 nix-repl> let a = 5; in with { a = 3; }; a 5 # ?????? > it it doesn't quickly jump out at you that ${VAR} are being templated in by nix One situation I've run into is how to quote ${ in a multiline string, and the solution is to write ''${ : nix-repl> '' ''${ '' "${ " > The documentation is fairly decent, but when trying to figure out how do something, you are basically hunting in that code base. This is very much true, essentially Nix and its ecosystem is a big instance of Hyrum's Law[0] whereby people go with what they actually observe rather than what should be according to the spec (if it exists). [0] https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
bamboozled 6y ago
I still don't understand the language syntax after using it for several years, I just make it work through trial an error. The documentation is pretty unhelpful too. It's ultra ambiguous. Recently my laptop died, and I just needed another one going in a hurry and I tried Xubuntu because it's the only distribution which had Wifi drivers that worked for a 12 year old Mac I had lying around without any trickery. It's funny because Nix worked fine, but my Ubuntu installation just stays out of my way and lets me work too. I started to make me question whether all the added Nix complexity really added much value. Would investing in learning Nix really pay off over spending my time learning a new programming language with real world application? I also think there is something to be said for the fact that, unless you team mates are using Nix,good luck using any of the standard tooling or scripts others will use. One of my favorites are shell scripts that start with `#!/bin/bash` never working and always having to patch them to use `#!/usr/bin/env bash` I understand the latter is the correct way to do things in 2021, but we all know it's not going to happen :)
- kaba0 6y ago
  Actually, I found the language to be pretty similar to Haskell, if you do know that. You don’t have explicit functions, you use let in, and everything is an exception. It is even lazy evaluating.
  - bamboozled 6y ago
    The lack of lazy evaluating is an issue as the Nixpkg grows. I don't believe anyone has a solution to this yet.
    - siraben 6y ago
      Could you elaborate what you mean by this? Nix has lazy evaluation so as Nixpkgs grows it doesn't perceptibly change how long package installations, building, etc. take.
      - tnzm 6y ago
tazjin 6y ago
I wrote a language tutorial for only the language a while back, and have gotten the feedback that it has helped a lot of people - maybe it'd clear something up for you: https://github.com/tazjin/nix-1p https://github.com/tazjin/nix-1p
carlmr 6y ago
I think not only documentation but a complete UX overhaul. The examples you find for creating a shell.nix usually work individually, but if you need a combination of two nix files there seem to be too many ways to do things, because I find it almost always impossible to combine two examples into one. Also for searching packages I always end up looking on the website. Using the built-in search you have to do some weird incantations that aren't easy to remember and you still don't get the full list of packages that are related. It also doesn't help that the package names are random. There's no standard format it seems: gcc 9 is "gcc9" while clang 9 is "clang_9". Why not have packages be <namespace>.<package>.<major[.minor[.build]]> or any other standard convention. Then you could also say you want a certain version of a package instead of having a name for each. Or a minimum version. Maybe we need a wrapper around nix that exposes a user friendly interface. I really like the basic idea.
thibran 6y ago
What took me a long time to understand is that there are different types of nix expressions (e.g. nix modules). For a long time I thought they are all the same. I hope nix flakes fixes the situation when they are released/stable.

domenkozar 6y ago

Did you follow the language tutorial in the manual or something else?

supermatt 6y ago
I would have followed the official manual. I see that you are putting together some tutorials, so I will definitely check those out.

throwaway894345 6y ago

I agree. I’ve spent person-weeks looking into Nix, and I still can’t get it to work beyond the most basic of use cases. A few weeks ago I spent an entire weekend on the Nix discord channel trying to get help to configure VSCode for Rust development, and we collectively couldn’t figure it out. Nix is a great idea, and it’s goals are ambitious, but I haven’t found it to be usable yet. Almost any time I try to do anything I get mired in a tar pit and I basically end up having to give up. I’ve learned lots of tools and technologies in my career, but Nix remains elusive.

domenkozar 6y ago
Do you have some examples of that? Maybe a link to discord discussion?
pimeys 6y ago
I did a month, diving directly into the deep end with flakes and all. I don't know, it really is hard in the beginning. Like, really hard. But eventually I got myself a setup I could use in my two laptops and workstation. A setup, that sets my home directory, all my programs and my custom desktop just the way I want. Everything is in the github repo, and installing with the flake will give me the exact experience I have in my other machines. I tend to use lots of custom tools and commands, that are really painful to install and setup for a new machine. With NixOS all of it is just one command away. But, I agree, it is REALLY HARD in the beginning to grasp things. Here's my configs if you want to see how I approached my own setup: https://github.com/pimeys/nixos https://github.com/pimeys/nixos
- throwaway894345 6y ago
  "It's hard to grasp things" is only one part of the problem. I mentioned that there's no good way to understand nixpkgs except to manually traverse the file tree. Grokking the directory scheme will help a bit, but there's no amount of Nix Nirvana that will make it as easy as hovering over the parameter in VS Code. In other cases, things are just broken--my nix installed rustup is failing to build packages this morning with a clang linker error (can't find iconv) and Googling the error message + 'rust' indicates that this problem is only encountered in Nix environments. Similarly, many of the other problems are that it requires you to repackage other libraries from the ground up. For example, most Python packages are available in Pypi such that users can just `pip install` them. Nixpkgs has a `pypiPackage` function that allows us to import a package from Pypi, but if that package has C dependencies (and many do, because Python's performance sucks and Python's performance sucks because everything depends on C packages precluding optimizations to the interpreter, but that's a gripe for another day) then Nix requires you to package those C dependencies in Nix first, and because every C package has its own bespoke build system with implicit dependencies, you must be expert in each individual C package in the dependency tree. Again, there's no amount of Nix Nirvana that will save you from this. In many other cases (e.g., my 'packaging vs code with my rust plugins' example from my earlier post) we have to know the specific conventions for specific nixpkgs functions which will vary from others, and even that might not be enough. These conventions can't be derived from any general understanding or intuition of Nix (i.e., "Nix Nirvana") although it certainly doesn't hurt. Further, NixOS is easy mode. It's the first class citizen in the Nix ecosystem. Other platforms don't work so well. In my vs code + rust plugins example, there were several posts documenting the process on NixOS, but for whatever reason Nix on other platforms (e.g., macOS) requires different configuration which is undocumented and even proficient Nix users couldn't figure out the issue. But yeah, to your point, it is really hard to grasp as well, which exacerbates all of the above problems.

ivanbakel 6y ago

I am of a similar opinion, but I think it's largely due to my typical use case. If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing small invocations or on-the-fly editing, the docs are much less useful. There's also no way to understand it in terms of a few simple concepts for beginners. Do you want an override, an overlay, a flake, or something else? Does specifying an option in multiple places combine them, or does one spec override the other? It feels as though Nix is a technology of special cases, and the docs don't make it easy to understand what to do in each case when all you know is the kind of change you want to make. The worst culprit of this is NixOS services, which each declare an ad-hoc API that I normally find myself digging into the service declaration file in the Nix repo to try and understand.

oblio 6y ago
> If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing small invocations or on-the-fly editing, the docs are much less useful. This is super serious, major, I hope the devs are paying attention. Most users of anything are drive-by, rather casual users. Think of any big tech out there: they became popular precisely because they were easy to get started (at least back when they were launched/became popular): C, Unix, Bash, Perl, PHP, MySQL, Javascript, Java, Ruby, Go, etc. Almost everything that's big was usable by people don't read an entire book before they can make "Hello world".
- Ericson2314 6y ago
  There are some serious gotchas like nix-env in this read I would like to delete. But, that said, I don't think targeting "drive by usesr" is worth it. The benefits of Nix is that it dramatically organizes the absolute disgusting mess that is how most people manage their computer. I don't want to drive people trying things out away, but Nix will never be worth it unless you embrace it, and half-ways usage will deliver all the downsides without enough of the upsides. Not every value function is monotonic like that, I am not going to pretend it's otherwise. The goal is to help people fully embrace it, not to allow them to comfortably come to a stand-still half way.

georgyo 6y ago

Having used nix for two years now for both work and personal purposes, I agree. Though I have also come to think nix is doing things in much better ways than AppImage, Docker, Snap, Flatpack, and others. I won't focus on the good parts, but focus on your comment. Nix has three things that I think are confusing and took me an embarrassing long time to grok, and I find other people confused by as well. 1. Where does the semicolon go? Reading code makes it feel arbitrary, but really the only time a semicolon is used is to terminate an assignment (=). If there are no equal signs, then you don't need any semicolons. 2. The heredoc strings ('' '') are in fact strings. Nixpkgs passes these strings to a shell quite frequently and their docs also make it feel like these statements are shell scripts and not strings. The problem here is that to pull a variable from nix you use ${VAR} and to use an environment variable you use $VAR. When you look at these heredocs it looks like a pure bash script, but it doesn't quickly jump out at you that ${VAR} are being templated in by nix. It also isn't obvious that $VAR is not being templated in by nix. 3. The nix language is very very tiny, and almost everything comes from nixpkgs which is basically stdlib as well as the package repository. Almost everything, including callPackage is in nixpkgs. The documentation is fairly decent, but when trying to figure out how do something, you are basically hunting in that code base. Bonus 4. In nix it is really easy to build single language applications. However if you need to mix two, finding good docs or examples is really hard. IE, if you want to build the javascript front end of your web app as well as the python backend. These combinations need at least two derivations, and how to make it happen is bespoke every time.

siraben 6y ago
Regular Nix user here, I agree with your points regarding the language's peculiarities, and adding on a few points: > 1. Where does the semicolon go? Reading code makes it feel arbitrary, but really the only time a semicolon is used is to terminate an assignment (=). If there are no equal signs, then you don't need any semicolons. The semicolon is also required when using with expressions (i.e. augments the environment of an expression like let, but confusingly doesn't shadow let bindings) nix-repl> with { a = 3; }; a 3 nix-repl> let a = 5; in with { a = 3; }; a 5 # ?????? > it it doesn't quickly jump out at you that ${VAR} are being templated in by nix One situation I've run into is how to quote ${ in a multiline string, and the solution is to write ''${ : nix-repl> '' ''${ '' "${ " > The documentation is fairly decent, but when trying to figure out how do something, you are basically hunting in that code base. This is very much true, essentially Nix and its ecosystem is a big instance of Hyrum's Law[0] whereby people go with what they actually observe rather than what should be according to the spec (if it exists). [0] https://www.hyrumslaw.com/ https://www.hyrumslaw.com/

bamboozled 6y ago

I still don't understand the language syntax after using it for several years, I just make it work through trial an error. The documentation is pretty unhelpful too. It's ultra ambiguous. Recently my laptop died, and I just needed another one going in a hurry and I tried Xubuntu because it's the only distribution which had Wifi drivers that worked for a 12 year old Mac I had lying around without any trickery. It's funny because Nix worked fine, but my Ubuntu installation just stays out of my way and lets me work too. I started to make me question whether all the added Nix complexity really added much value. Would investing in learning Nix really pay off over spending my time learning a new programming language with real world application? I also think there is something to be said for the fact that, unless you team mates are using Nix,good luck using any of the standard tooling or scripts others will use. One of my favorites are shell scripts that start with `#!/bin/bash` never working and always having to patch them to use `#!/usr/bin/env bash` I understand the latter is the correct way to do things in 2021, but we all know it's not going to happen :)

kaba0 6y ago
Actually, I found the language to be pretty similar to Haskell, if you do know that. You don’t have explicit functions, you use let in, and everything is an exception. It is even lazy evaluating.
- bamboozled 6y ago
  The lack of lazy evaluating is an issue as the Nixpkg grows. I don't believe anyone has a solution to this yet.
  - siraben 6y ago
    Could you elaborate what you mean by this? Nix has lazy evaluation so as Nixpkgs grows it doesn't perceptibly change how long package installations, building, etc. take.
    - tnzm 6y ago

tazjin 6y ago

I wrote a language tutorial for only the language a while back, and have gotten the feedback that it has helped a lot of people - maybe it'd clear something up for you: https://github.com/tazjin/nix-1p https://github.com/tazjin/nix-1p

carlmr 6y ago

I think not only documentation but a complete UX overhaul. The examples you find for creating a shell.nix usually work individually, but if you need a combination of two nix files there seem to be too many ways to do things, because I find it almost always impossible to combine two examples into one. Also for searching packages I always end up looking on the website. Using the built-in search you have to do some weird incantations that aren't easy to remember and you still don't get the full list of packages that are related. It also doesn't help that the package names are random. There's no standard format it seems: gcc 9 is "gcc9" while clang 9 is "clang_9". Why not have packages be <namespace>.<package>.<major[.minor[.build]]> or any other standard convention. Then you could also say you want a certain version of a package instead of having a name for each. Or a minimum version. Maybe we need a wrapper around nix that exposes a user friendly interface. I really like the basic idea.

thibran 6y ago

What took me a long time to understand is that there are different types of nix expressions (e.g. nix modules). For a long time I thought they are all the same. I hope nix flakes fixes the situation when they are released/stable.