 | Lix Development | 423 Members |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 140 Servers |
| Lix Development | 423 Members |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 140 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Mar 2026 | ||
 raitobezarius | incompleteness of a derivation is yet another example and is driven by the lack of instrumented recursive evaluation of attribute sets IMHO, there's no way to perform fancy traversal of these graphs with impure action responses | 22:33:04 |
| raitobezarius | nix-eval-jobs is one instrumented recursive evaluation of attribute sets meant as a porcelain to build more complicated tooling, it theoretically can also do way more than tryEval-based techniques because it has full access into the C++ evaluator primitives and can catch the uncatchable (modulo impl details) | 22:33:56 |
| raitobezarius | yeah, i have been aligned with horrors for a long time on this | 22:35:02 |
| raitobezarius | if we could create the conditions to remove that weird exception handling fragment, that'd be great | 22:36:13 |
| raitobezarius | i don't mind replacing it with Result<T, E> though I think as I said: it's a dream, I don't see that realistic compared to do it right in nix2 | 22:36:52 |
 zoë (she/her) | i do agree with that tbf, and i think the FOD error is a good example of something that doesn't make sense to make catchable; but i don't think all errors should be that way. while in general, things related to bare derivations and building probably aren't gonna be the most useful to catch, the fact you can't run/use any nix expression inside your code without the fear that it might fatally throw is a little frustrating imo. if we did have a Result type it'd obviously be preferable to exceptions, but for the foreseeable future we won't, so i do think it's useful to be able to tell if e.g. some packages fail to eval in nixpkgs, or a property of a object we computed actually throws, etc | 22:46:42 |
| zoë (she/her) | anyway, i think i should maybe stop here, i don't have the same experience and "vision for nix" that most people have here ^^; | 22:47:23 |
| raitobezarius | i agree | 22:47:25 |
| raitobezarius | i think that approaching this problem from different perspective is welcome; but i think: for the exercise to be interesting, it needs to be thorough | 22:48:03 |
| raitobezarius | that is, for each current catchable/uncatchable behavior, providing a rationale for its current status or a rationale to change it | 22:48:23 |
| raitobezarius | i know that i did that when i finished most of the catchable/uncatchable impl in https://snix.dev (which doesn't rely on exceptions but proper Result<T, E> at the Rust level) and i acquired some taste along the fun | 22:48:54 |
| raitobezarius | otherwise, we are kinda condemned into discussing n=1,2,3 examples and i'm not sure this will lead to a satisfying design overall | 22:49:28 |
| raitobezarius | to put it in another way: do not let grand words like "vision for nix" discourage you from finding out your own opinions and communicating them | 22:50:06 |
| raitobezarius | but i'd appreciate reading an overall coherent set of opinions if you find the time to do it ;-) | 22:50:17 |
| raitobezarius | (not saying you don't provide a coherent set of opinions atm, but more like, this is what i would like to read from a different perspective) | 22:50:41 |
 piegames | In reply to @blokyk:matrix.orgBasically at the core is the following problem: any fallibility which may depend on impure outside context propagates that impurity into the language if caught. I agree that not being able to catch runtime type errors is annoying though, and this may be fixable, but no guarantees (also a pproper type system would instant fix this entire class of issues) | 22:51:03 |
| zoë (she/her) | (i am somewhat reminded of the line i saw in last month's core team meting:
| 22:51:27 |
| zoë (she/her) | * (i am somewhat reminded of the line i saw in last month's core team meting:
and seeing everyone's very interesting ideas compared to just the "nix is fun :D functional programming is fun :D if only haskell $ operator tho :( and also not cursed :((" idea i have definitely makes me kinda resonate with that line (which, obviously no problem with that, i am a pretty boring person in general) x) | 22:52:06 |
| zoë (she/her) |
yeah, nix's lack of a type system is probably my biggest gripe with it; even stripping the cursed/badly designed parts of it, the dynamic nature makes writing nix just landmine after landmine | 22:52:57 |
| zoë (she/her) | anyway i do agree with the solution of making externally-caused errors uncatchable, that makes complete sense to me; it's really mostly runtime errors that annoy me | 22:55:47 |
| zoë (she/her) | * anyway i do agree with the solution of making externally-caused errors uncatchable, that makes complete sense to me; it's really mostly runtime errors that frustrate me | 22:55:52 |
| zoë (she/her) | i really shouldn't have been, but i was genuinely surprised that the actual evaluator uses c++ exceptions to propagate eval/user-facing errors, instead of using a result type; it just felt... dirty. again, really shouldn't have been surprised, it is the nix codebase after all x) | 22:58:57 |
| raitobezarius | my lawyer does not allow me to comment on these matters | 22:59:15 |
| zoë (she/her) | xD | 22:59:23 |
| zoë (she/her) | fair enough | 22:59:30 |
| raitobezarius | it's important to imagine Nix as a 20 years old technology | 22:59:43 |
| piegames | In reply to @blokyk:matrix.orgTo be fair: try using Result types in C++ in 2005 | 22:59:47 |
| raitobezarius | it's also important to imagine that (technical) debt payment have not been popular | 23:00:11 |
| zoë (she/her) | i know i know, nix's 2000s-phd-thesis nature keeps catching up to it | 23:00:21 |
| raitobezarius | * it's also important to imagine that (technical) debt payment has not been popular | 23:00:22 |