3 ms·
the result infinite loop issue is easily the most confusing part of nix. It works because nix is a lazy functional language. But I'm not particularly sold on th
by zaphar 5y ago
the result infinite loop issue is easily the most confusing part of nix. It works because nix is a lazy functional language. But I'm not particularly sold on that laziness being useful since it leads to awkward hacks like the two arguments to an overlay function. It has the one benefit of allowing you to not care about the order that overlays get called in. However it does that by giving your code magical come from semantics that make debugging a problem harder than it needs to be. I think the nix lazy semantics would actually have been better left out in favor of clearer dependency semantics.
In a way the clearer dependency semantics of flakes are are driving the reason they are increasing in adoption so much. In essence they work around the problems introduced by overly clever usage of laziness in a nix package.
- chriswarbo 5y ago> But I'm not particularly sold on that laziness being useful since it leads to awkward hacks like the two arguments to an overlay function. It has the one benefit of allowing you to not care about the order that overlays get called in. However it does that by giving your code magical come from semantics that make debugging a problem harder than it needs to be. I don't consider it an awkward hack; it's a very standard least-fixed-point calculation. Developers these days seem comfortable-enough with 'self' and 'super' in OOP; that fixed-point pattern is essentially the same, but without shoe-horning magic keywords into the language.
- zaphar 5y agoI think you could get 99% of the value of an overlay as a simple fold or map over the result. Introducing the second argument feels very much like a workaround to allow you to avoid the infinite loop.