4 ms·

I actually hate Nix.. and i agree, i'm never going back. I use it on my desktop (Linux), my Macbooks, and i want it on my Windows machine (not that it's going t

I actually hate Nix.. and i agree, i'm never going back. I use it on my desktop (Linux), my Macbooks, and i want it on my Windows machine (not that it's going to happen hah). The thing that Nix, for me, currently fails at is introspection. Every function is a black box and i have no clue what's in it. I have to go dig up files on github to see what it even accepts. It's as if everything is obtuse. A "simple" LSP/Type system would do wonders for understanding what the function is, what it does, and the inputs/outputs. .. also i have some difficulty understanding functional "mutation" patterns like how overloads are implemented. But i hope that'll make sense eventually. NOTE: i also think Flakes are absolutely necessary for Nix. Nix is way less valuable to me without Flakes.

skoskie 5y ago
Guess I know what I’m learning this weekend. Anyone have tutorials they want to share?
- mikepurvis 5y ago
  I'm about a year into Nix and consider myself a moderate in some areas but something of an expert (by necessity) in others. I think the ideal pattern is to attack it bottom-up and top-down at the same time. Bottom up, you want to learn the fundamentals of how the Nix language works, and how the basic primitives it offers can be used to build up package definitions, a package manager, and ultimately an entire OS. For this, the Nix Pills are invaluable: https://nixos.org/guides/nix-pills/ https://nixos.org/guides/nix-pills/ Top down, you need goals for some specific things you want to accomplish in the system. For me, this was automated packaging for hundreds of source repos internal to my company, but that's a bit of a crazy case— for a normal person, I'd expect this could be something like "I want to run a webserver with some static assets" or "I want to define and launch a container declaratively", or maybe "I want a reproducible environment to do Python development in, where the reproducibility isn't just tagged versions in a requirements/pyproject file, but also includes the full underlay of everything I'm depending on from the base system. Whatever the goal is here, you're inevitably going to find your way to override-related tasks, like "okay, I want to upgrade this package" or "I want to add patches to this package" or "I want to change the settings on one of my dependencies", and that's where the extraordinary power of Nix really starts to sink in, when you realise how much can be accomplished with so little, and you try to imagine what accomplishing that under a conventional apt- or dnf-type system would look like.
- JamesSwift 5y ago
  I would read a bit and look at the nix-pills [1] even though I could never understand them when I was learning. Then, what I always recommend is this playlist by Burke Libbey on youtube [2]. There are a couple fundamental things that you can internalize which will make everything much more approachable: 1. Nix the language is basically a JSON object. Almost everything is about generating and composing subtrees to build a _really_ big JSON object. 2. `<foo>` means from channel `foo`. This is less relevant now with flakes but that was always extremely confusing syntax to me and when I "got it" it made things way easier. [1] - https://nixos.org/guides/nix-pills/ https://nixos.org/guides/nix-pills/ [2] - https://www.youtube.com/watch?v=NYyImy-lqaA&list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/watch?v=NYyImy-lqaA&list=PLRGI9KQ3_H...
JamesSwift 5y ago
Agreed on Flakes. It both makes the entire thing much more pure in terms of its guarantees about reproducibility/portability as well as being a lot easier to understand for me as a non-expert consumer.
- mikepurvis 5y ago
  As a learner myself over the past year, I also strongly prefer the flake workflow— the tooling design makes more sense, there's no implicit magic about where your inputs are coming from, and everything is pure by default. Not to mention the absolute delight that is the `--override-input` flag— being able to layer your project into multiple flakes and then trivially rebuild it with just one part overridden from a modified local source, so great. But yeah, it's super frustrating that it's all still hidden behind experimental flags and the official documentation continues to suggest non-flake workflows, though. It's ready for primetime— commit to it please!

skoskie 5y ago

Guess I know what I’m learning this weekend. Anyone have tutorials they want to share?

mikepurvis 5y ago
I'm about a year into Nix and consider myself a moderate in some areas but something of an expert (by necessity) in others. I think the ideal pattern is to attack it bottom-up and top-down at the same time. Bottom up, you want to learn the fundamentals of how the Nix language works, and how the basic primitives it offers can be used to build up package definitions, a package manager, and ultimately an entire OS. For this, the Nix Pills are invaluable: https://nixos.org/guides/nix-pills/ https://nixos.org/guides/nix-pills/ Top down, you need goals for some specific things you want to accomplish in the system. For me, this was automated packaging for hundreds of source repos internal to my company, but that's a bit of a crazy case— for a normal person, I'd expect this could be something like "I want to run a webserver with some static assets" or "I want to define and launch a container declaratively", or maybe "I want a reproducible environment to do Python development in, where the reproducibility isn't just tagged versions in a requirements/pyproject file, but also includes the full underlay of everything I'm depending on from the base system. Whatever the goal is here, you're inevitably going to find your way to override-related tasks, like "okay, I want to upgrade this package" or "I want to add patches to this package" or "I want to change the settings on one of my dependencies", and that's where the extraordinary power of Nix really starts to sink in, when you realise how much can be accomplished with so little, and you try to imagine what accomplishing that under a conventional apt- or dnf-type system would look like.
JamesSwift 5y ago
I would read a bit and look at the nix-pills [1] even though I could never understand them when I was learning. Then, what I always recommend is this playlist by Burke Libbey on youtube [2]. There are a couple fundamental things that you can internalize which will make everything much more approachable: 1. Nix the language is basically a JSON object. Almost everything is about generating and composing subtrees to build a _really_ big JSON object. 2. `<foo>` means from channel `foo`. This is less relevant now with flakes but that was always extremely confusing syntax to me and when I "got it" it made things way easier. [1] - https://nixos.org/guides/nix-pills/ https://nixos.org/guides/nix-pills/ [2] - https://www.youtube.com/watch?v=NYyImy-lqaA&list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/watch?v=NYyImy-lqaA&list=PLRGI9KQ3_H...

JamesSwift 5y ago

Agreed on Flakes. It both makes the entire thing much more pure in terms of its guarantees about reproducibility/portability as well as being a lot easier to understand for me as a non-expert consumer.

mikepurvis 5y ago
As a learner myself over the past year, I also strongly prefer the flake workflow— the tooling design makes more sense, there's no implicit magic about where your inputs are coming from, and everything is pure by default. Not to mention the absolute delight that is the `--override-input` flag— being able to layer your project into multiple flakes and then trivially rebuild it with just one part overridden from a modified local source, so great. But yeah, it's super frustrating that it's all still hidden behind experimental flags and the official documentation continues to suggest non-flake workflows, though. It's ready for primetime— commit to it please!