4 ms·

I tried to learn before. But the docs made it incredibly hard. They went into excruciating detail of how it works. I still never made my own nix package. I’m wo

I tried to learn before. But the docs made it incredibly hard. They went into excruciating detail of how it works. I still never made my own nix package. I’m wondering as a solo dev, who uses his personal machine, and two servers, if the hard work of learning it will pay off. But it definitely looks interesting.

domenkozar 6y ago
What kind of tutorial would you like to read?
- tarkin2 6y ago
  Something more like “And now you can do this” rather than “And now you know how it works “. The docs for using nix as a package manager are decent. But the rest, less so. They’re a recursive rabbit hole of confusion.
  - elbear 6y ago
    I found useful this series of articles introducing Nix by using it with Haskell: https://github.com/Gabriel439/haskell-nix https://github.com/Gabriel439/haskell-nix I hope it helps.
- JackC 6y ago
  My dream tutorial shows how to move from what I have to the new thing, because that teaches me what new ways of thinking I need to adopt. Like right now at work we have a small team making a website with docker-compose to specify the dev environment, pip-tools to pin python dependencies, and saltstack to deploy new state to bare metal in production. How exactly, command by command, would nix solve the same problems? What would change from my current solution? How would I think differently? How would my life get better? What parts wouldn't be solved and I'd have to keep some of the old stuff around? Those are the tutorials that convince me to switch, because they get me over the hump of not getting the new paradigm, and being afraid of the downsides I don't know about yet. It's tricky because it's pretty specific to how someone's currently solving problems, but maybe knowing what I'd optimally want can help with figuring out something doable. (This blog post didn't work for me because it was too vague. I already have old boring solutions for their python pain points, like pip-tools, so I can't take their assessment of how much better things can be on faith, and they don't show me the details of the new thing.)
  - q3k 6y ago
    > How exactly, command by command, would nix solve the same problems? This might be problematic, because to understand these commands, you would have to understand Nix. It's not just a tool that replaces your existing tool, it's a total workflow change, and without understanding what's happening under the hood, you can't really appreciate how much it makes your life easier. I could show you a `nix-build -A deploy.somemachine`, but without understanding why it's called like that, and what exactly it does, and how I build most of that myself using nixpkgs tooling, you wouldn't really 'get' it, because you probably wouldn't understand how is that better than doing an `ansible-playbook -i foo.yml`, and I wouldn't be able to explain without explaining Nix/nixpkgs from scratch. Nix, compared to other DevOps tools, is alien technology, and requires unlearning a lot of things, learning a whole new language and ecosystem, beginning to think in terms of that ecosystem and general programmability and functional programming, and then building on top of this to solve your problems. Nix doesn't immediately bring solutions to your problems, it brings you a new way of thinking about these problems and solving them in ways you didn't even consider before. I know this is all handwavy, and that is unfortunate, but in my opinion unavoidable when dealing with radically different tooling. From my experience, the current 'classic' devops tooling (Docker, Terraform, ...) has reached a local maximum of usability. Getting out of that maximum requires a vastly different approach, and thus requires a much longer learning experience than what most people are used to. If you keep switching to different tools that behave how you expected them to, you're really just using the same thing as before, but with a different syntax.
    - tnzm 6y ago
      >This might be problematic, because to understand these commands, you would have to understand Nix. It's not just a tool that replaces your existing tool, it's a total workflow change, and without understanding what's happening under the hood, you can't really appreciate how much it makes your life easier. That's the entire point of a tutorial like GP describes. Yes, Nix works on a higher level of abstraction than existing tools, but it solves the same problem, and comparing it to "alien technology" doesn't help. Nix is simply: * a large corpus of work (nixpkgs; which contains build instructions for source code that can combine all the way to an operating system or a service image) * organized in a particular way (using the Nix language; used to declare the expected results of all the different build strategies out there) * and coupled to the tools that let you turn a description of a process into the result of that process (nix-build, etc). This is abstract but hopefully less handwavy? The concrete details of the Nix paradigm really lie in the syntax itself so what you're saying about "same tools with different syntax" doesn't make much sense to me, as every programming tool is defined by its syntax. The on-ramps to becoming fluent with the Nix language are, admittedly, subpar. I got nearly nothing out of "nix-pills" and cringe every time someone recommends that tutorial which takes 10 chapters to build your first package in the most roundabout way possible. What Nix needs is a single page specifying what goes in a Nix derivation. Like the Compose YML reference but simpler. Also the nixpkgs manual is quite central but impenetrable for casual reading. Also how about someone writing a tutorial for generating a static HTML site with Nix, then deploying it, then incrementally adding dynamic backend services to it?
- takeda 6y ago
  I don't think it fits the tutorials you're creating on nix.dev, but I would love a deep dive how to use module system that nixpkgs provides. What I mean is how to use it to create my own solution. For example if I would create own configuration file like flake.nix or configuration.nix how could I process it. I think I figured it out, but I'm still not certain if I'm using it correctly.

domenkozar 6y ago

What kind of tutorial would you like to read?

tarkin2 6y ago
Something more like “And now you can do this” rather than “And now you know how it works “. The docs for using nix as a package manager are decent. But the rest, less so. They’re a recursive rabbit hole of confusion.
- elbear 6y ago
  I found useful this series of articles introducing Nix by using it with Haskell: https://github.com/Gabriel439/haskell-nix https://github.com/Gabriel439/haskell-nix I hope it helps.
JackC 6y ago
My dream tutorial shows how to move from what I have to the new thing, because that teaches me what new ways of thinking I need to adopt. Like right now at work we have a small team making a website with docker-compose to specify the dev environment, pip-tools to pin python dependencies, and saltstack to deploy new state to bare metal in production. How exactly, command by command, would nix solve the same problems? What would change from my current solution? How would I think differently? How would my life get better? What parts wouldn't be solved and I'd have to keep some of the old stuff around? Those are the tutorials that convince me to switch, because they get me over the hump of not getting the new paradigm, and being afraid of the downsides I don't know about yet. It's tricky because it's pretty specific to how someone's currently solving problems, but maybe knowing what I'd optimally want can help with figuring out something doable. (This blog post didn't work for me because it was too vague. I already have old boring solutions for their python pain points, like pip-tools, so I can't take their assessment of how much better things can be on faith, and they don't show me the details of the new thing.)
- q3k 6y ago
  > How exactly, command by command, would nix solve the same problems? This might be problematic, because to understand these commands, you would have to understand Nix. It's not just a tool that replaces your existing tool, it's a total workflow change, and without understanding what's happening under the hood, you can't really appreciate how much it makes your life easier. I could show you a `nix-build -A deploy.somemachine`, but without understanding why it's called like that, and what exactly it does, and how I build most of that myself using nixpkgs tooling, you wouldn't really 'get' it, because you probably wouldn't understand how is that better than doing an `ansible-playbook -i foo.yml`, and I wouldn't be able to explain without explaining Nix/nixpkgs from scratch. Nix, compared to other DevOps tools, is alien technology, and requires unlearning a lot of things, learning a whole new language and ecosystem, beginning to think in terms of that ecosystem and general programmability and functional programming, and then building on top of this to solve your problems. Nix doesn't immediately bring solutions to your problems, it brings you a new way of thinking about these problems and solving them in ways you didn't even consider before. I know this is all handwavy, and that is unfortunate, but in my opinion unavoidable when dealing with radically different tooling. From my experience, the current 'classic' devops tooling (Docker, Terraform, ...) has reached a local maximum of usability. Getting out of that maximum requires a vastly different approach, and thus requires a much longer learning experience than what most people are used to. If you keep switching to different tools that behave how you expected them to, you're really just using the same thing as before, but with a different syntax.
  - tnzm 6y ago
    >This might be problematic, because to understand these commands, you would have to understand Nix. It's not just a tool that replaces your existing tool, it's a total workflow change, and without understanding what's happening under the hood, you can't really appreciate how much it makes your life easier. That's the entire point of a tutorial like GP describes. Yes, Nix works on a higher level of abstraction than existing tools, but it solves the same problem, and comparing it to "alien technology" doesn't help. Nix is simply: * a large corpus of work (nixpkgs; which contains build instructions for source code that can combine all the way to an operating system or a service image) * organized in a particular way (using the Nix language; used to declare the expected results of all the different build strategies out there) * and coupled to the tools that let you turn a description of a process into the result of that process (nix-build, etc). This is abstract but hopefully less handwavy? The concrete details of the Nix paradigm really lie in the syntax itself so what you're saying about "same tools with different syntax" doesn't make much sense to me, as every programming tool is defined by its syntax. The on-ramps to becoming fluent with the Nix language are, admittedly, subpar. I got nearly nothing out of "nix-pills" and cringe every time someone recommends that tutorial which takes 10 chapters to build your first package in the most roundabout way possible. What Nix needs is a single page specifying what goes in a Nix derivation. Like the Compose YML reference but simpler. Also the nixpkgs manual is quite central but impenetrable for casual reading. Also how about someone writing a tutorial for generating a static HTML site with Nix, then deploying it, then incrementally adding dynamic backend services to it?
takeda 6y ago
I don't think it fits the tutorials you're creating on nix.dev, but I would love a deep dive how to use module system that nixpkgs provides. What I mean is how to use it to create my own solution. For example if I would create own configuration file like flake.nix or configuration.nix how could I process it. I think I figured it out, but I'm still not certain if I'm using it correctly.