| 12 Dec 2025 |
 emily | which sort of scuppers it as a model for Nix | 13:54:24 |
| emily | eh, maybe you could with enough memoization. wouldn't work for polymorphic recursion but that's a high bar. | 13:55:11 |
 Arian | cue doesn’t have functions. it’s more a model of the NixOS module system; not of nix | 13:55:12 |
| Arian | my thesis is that nix is a terrible host language for the NixOS module system :P | 13:55:20 |
| emily | yeah | 13:56:08 |
| emily | well I don't like the module system anyway, it's too global. throws away half of the properties that make Nix nice for package graphs. | 13:56:34 |
 KFears (they/them) | I really like modules. Functional package graphs get weird and very global when splicing and pkgsStatic and build variants become a thing | 16:06:05 |
| emily | I don't think the module system solves the issue of variant sets | 16:24:52 |
| emily | (it just doesn't really have to deal with it in practice since people do the equivalent thing with NixOS much less, although still not zero) | 16:25:33 |
| emily | the equivalent of NixOS modules for the package set would be if every package definition in Nixpkgs could monkey-patch any other package arbitrarily | 16:26:32 |
 llakala | In reply to @emilazy:matrix.org
well I don't like the module system anyway, it's too global. throws away half of the properties that make Nix nice for package graphs. i will plug my fav alternate module system | 18:17:22 |
| llakala | https://github.com/adisbladis/adios | 18:17:42 |
| llakala | it's basically what I always wanted in a module system | 18:18:20 |
| llakala | where it only evaluates the modules you actually use | 18:18:35 |
| llakala | i did some eval profiling for my use of it and it only adds about 2% extra evaluation time - the rest is just from the drvs | 18:19:43 |
