>I see words like “flakes” and “derivations,” and I currently don’t know what they mean. >So far, I don’t get how it’s deterministic. To make nix deterministic you can specify a hash in non-flakes (or a git rev) for your dependencies, but flakes make this easier. When you "run" a flake (be it nix build, nix shell, nix develop), nix pulls the latest (if no explicit rev given in the flake.nix already) version of whatev…
My First Impressions of Nix
211–220 of 354 posts
Re: My First Impressions of Nix
#212Earlier quoted context omitted.
Explaining what Nix is seems like one of its biggest barriers to adoption. Part of the difficulty is it means different things to different people. My colleague spent a whole lot of time trying to answer this question and ended up with this: My main take away after spending some time learning about Nix is that it embraces the functional programming concept of a pure function. If I give a function a certain set of inp…
The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…
Re: My First Impressions of Nix
#213Earlier quoted context omitted.
> Is it fair to summize that python applications with python dependencies do not really work well as nix packages and shouldn't be used? No, applications that are properly maintained work as they should and this can be ensured with tests and e2e tests.
This is such a condescending attitude. What you mean is applications that are maintained the way that you and the Nix developers think an application should be maintained. It's incredibly naive for a package manager as ambitious as Nix to assume semver. I'm a big fan of semver myself, but the vast majority of software projects follow it imperfectly or not at all, and for good reason—it's nearly impossible to follow i…
Re: My First Impressions of Nix
#214Re: My First Impressions of Nix
#215Earlier quoted context omitted.
With FHS I'd say it does 3 also.
FHS makes it more similar, but not compatible. I'll quote from my blog post linked above: > Different distributions make different choices, and therefore they are closely related operating systems, but not a single OS. Even Linux syscall interface subtly changes from distribution to distribution, as they pick and choose options to build their kernels. > Every niche Linux distribution that does not follow the interfac…
Re: My First Impressions of Nix
#216Earlier quoted context omitted.
Go with Ansible unless you want to fully dedicate into Nix ecosystem and spend a lot of time learning it (and it's not easy, for example because of lacking documentation). Also Ansible is something you more often find in actual projects/workplace.
well, yes true, but ansible sucks and especially for small and chaotic projects where people just change things on the machines without reflecting it in ansible it is a nightmare
Re: My First Impressions of Nix
#217Earlier quoted context omitted.
Did you read the entire comment? The core idea of functional programming is pure functions (given the same outputs, the output is always the same). Nix applies that to building systems.
Pure functions are just a concept that is used in FP world Yet, pure functions can "stand alone". You do not need FP to use pure functions. They are independent from FP. You can be OOP maniac and still use them. So unless you want to sound fancy and trendy then why call Nix functional instead of side-effects free?
This is not true. OOP is fundamentally built around impure operations.
Objects are persistent references that you send messages to or that you call methods on (depending on your OOP language of choice).
A persistent reference that is stable across different invocations (as opposed to a new reference being created on each invocation) requires that those invocations be impure operations, because the same invocation performed multiple times must have different effects, otherwise there is no point to having a stable reference.
That's not necessarily a bad thing, but OOP is fundamentally impure.
(If you do create a new reference on every invocation, then you no longer have OOP. You merely have a namespacing system where the first argument to a function can alternatively be written with a dot).
Re: My First Impressions of Nix
#218> A lot of Nix documentation I’ve found says things like, “Simply add these lines!” > Huh? > Which file? And where in the file do I add those lines? This issue is prevalent everywhere . Even the best documented projects fail into this trap almost immediately.
Re: My First Impressions of Nix
#219Earlier quoted context omitted.
You don't have to manage your system with NixOS to reap the benefits of Nix. It solves very real problems that very much exist, it might not exist if you're a one-man show deploying WordPress to GoDaddy though. Barrier to entry: 1. Run the nix installer 2. Enable flakes 3. cd project 4. nix run This ensures you run the package with every dependency except the kernel pinned to a hashed version. If dependency hell is n…
> Run the nix installer Ok and this requires root access, sets up some global directories under root, and a new user. Me as the administrator: why the hell do I need a new user and what is the nix store and what are the conditions that mutate it? (I know the answers to this question, but it's a barrier for people who give a shit). > Enable flakes What the fuck is a flake? Reads a bit... what the fuck is a derivation?…
Re: My First Impressions of Nix
#220Earlier quoted context omitted.
You don't have to manage your system with NixOS to reap the benefits of Nix. It solves very real problems that very much exist, it might not exist if you're a one-man show deploying WordPress to GoDaddy though. Barrier to entry: 1. Run the nix installer 2. Enable flakes 3. cd project 4. nix run This ensures you run the package with every dependency except the kernel pinned to a hashed version. If dependency hell is n…
You're omitting the entire thing about learning how to write nix. Which is nightmare fuel even for FP fans.
The language is maybe a little strange at first but there's really not much to it.