Lix Development | 424 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 | ||
| but i'd appreciate reading an overall coherent set of opinions if you find the time to do it ;-) | 22:50:17 | |
| (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 | |
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 | |
| (i am somewhat reminded of the line i saw in last month's core team meting:
| 22:51:27 | |
| * (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 | |
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 | |
| 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 | |
| * 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 | |
| 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 | |
| my lawyer does not allow me to comment on these matters | 22:59:15 | |
| xD | 22:59:23 | |
| fair enough | 22:59:30 | |
| it's important to imagine Nix as a 20 years old technology | 22:59:43 | |
In reply to @blokyk:matrix.orgTo be fair: try using Result types in C++ in 2005 | 22:59:47 | |
| it's also important to imagine that (technical) debt payment have not been popular | 23:00:11 | |
| i know i know, nix's 2000s-phd-thesis nature keeps catching up to it | 23:00:21 | |
| * it's also important to imagine that (technical) debt payment has not been popular | 23:00:22 | |
| * i know i know, i've very much noticed that nix's 2000s-phd-thesis nature keeps catching up to it :| | 23:00:52 | |
| * i know i know, i've very much noticed that nix's 2000s-phd-thesis nature keeps catching up to it :( | 23:00:54 | |
| * i know i know, i've very much noticed that nix's 2000s-phd-thesis nature keeps catching up to it :/ | 23:00:55 | |
| * i know i know, i've very much noticed that nix's 2000s-phd-thesis nature keeps catching up to it :| | 23:00:57 | |
| * i know i know, i've very much noticed that nix's 2000s-phd-thesis nature keeps catching up to it :/ | 23:01:01 | |
| * i know i know, i've very much noticed that nix's 2000s+phd-thesis nature keeps catching up to it :/ | 23:03:13 | |
| * (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, yeah i am objectively a pretty boring person) x) | 23:23:43 | |
* with all that said, i still do have a question: should it be tagged E/Easy (with the notes from this discussion) and left to be first-time/drive-by contributed? it's not very urgent, and though it doesn't go into the c++ part of the codebase like most other changes will require, i still think it can be a good exercise, especially if combined with some tests | 23:38:22 | |
| 24 Mar 2026 | ||
| * (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, yeah i am objectively a pretty boring person, and i'm trying to believe that's okay) x) | 00:20:16 | |
| alright i tried to sum it up based on what i understood, but i'm not very confident in that, don't hesitate to tell me if i misinterpreted/misunderstood/misframed something | 00:23:59 | |
| * alright i tried to sum it up based on what i understood, but i'm not very confident in that, don't hesitate to tell me if i misinterpreted/misunderstood/misframed something | 00:34:19 | |
| lgtm | 05:35:46 | |
| The idea of technical debt collector comes to mind, anyway. | 08:43:39 | |