| 4 Apr 2025 |
 tea | Actual (new) use for dyndrv: https//github.com/pdtpartners/nix-ninja | 05:48:22 |
 helle (just a stray cat girl) | oh, right, if I spend like 30 minutes I should be able to pull a backup of a failed laptop and go back to doc fixes | 06:46:17 |
 KFears (burning out) | Controversial opinion: I think "experimental features" machinery is bad and lends itself into populating the codebase with many nested if-else branches (which is already a problem) with hard-to-improve designs | 10:15:56 |
| KFears (burning out) | Unfortunately, current "experimental features" design and lifecycle is more or less a source of technical debt, and the reasons to mark something as experimental has more to do with governance and difficulties in ensuring that the feature doesn't introduce 500 regressions in other usage | 10:18:20 |
 joepie91 🏳️🌈 | I'm not sure I agree with the reasons part - 'experimental features' also serve the usecase of "we know what kind of problem we're solving, but not yet what its exact shape is, and it's difficult or impossible to establish the optimal solution without just trying stuff out, but once we implement something we can't remove it anymore" | 11:35:49 |
| joepie91 🏳️🌈 | without some way to have an implementation that is usable but with the expectation of future breakage, you are left with the options of "try to design in a vacuum" or "try a first approximation and stick with it forever even if it sucks", neither of which are likely to have very good outcomes for the hairier problems | 11:36:40 |
| helle (just a stray cat girl) | does make us lean towards the question can we make it possible to do this without so many if-else branches throughout the code base? (which probably means more modularity of the code to begin with, which is going to probably be a rewrite nightmare itself, so yeah..... we know it is probably unreasonable) | 12:14:06 |
 raitobezarius | I don't agree that XP features are always a if-else branching | 12:35:15 |
| raitobezarius | Many of the abstractions can handle them without that branching | 12:35:25 |
| raitobezarius | It's just that some features doesn't need a composition layer to avoid the if-else branching and of course there's technical debt | 12:35:49 |
| raitobezarius | But generally having too many experimental features is a bit hard | 12:38:09 |
| KFears (burning out) | In reply to @joepie91:pixie.town
I'm not sure I agree with the reasons part - 'experimental features' also serve the usecase of "we know what kind of problem we're solving, but not yet what its exact shape is, and it's difficult or impossible to establish the optimal solution without just trying stuff out, but once we implement something we can't remove it anymore" The issue is, current experimental feature infra doesn't really provide this. It is less of a conceptual problem and more of a practical problem: there are many experiments features we inherit from CppNix, they can touch similar code paths and intersect in painful ways, and many experimental features have stagnated for years, and having people depend on them means it's hard to change them | 12:40:41 |
| KFears (burning out) | Like, we aren't Rust nightly that has a very large amount of flags, where some get stabilized, some get breaking changes, and some get phased out for other, better flags | 12:42:01 |
| joepie91 🏳️🌈 | I understood your comment to be about "experimental features machinery" as a category rather than the current implementation in cppnix | 12:46:05 |
| joepie91 🏳️🌈 | * I understood your comment to be about "experimental features machinery" as a category rather than just the current implementation in cppnix | 12:46:21 |
| KFears (burning out) | I mean, just talking about stable manual, there are many problematic ones: repl-flake should've never been behind a flag, ca-drv are busted, toml-timestamps - why is that a feature flag... | 12:48:13 |
| joepie91 🏳️🌈 | so could you clarify whether this comment was intended to refer to "experimental features machinery" as a category, or specifically to the implementation of the concept that currently exists in cppnix/lix? | 12:50:57 |
| KFears (burning out) | In reply to @joepie91:pixie.town
I understood your comment to be about "experimental features machinery" as a category rather than the current implementation in cppnix Oh, my bad
I think current experimental features can by and large be stabilized or purged from the codebase. In principle, feature flags are fine, but their scope should be less, and their value depends very much on the layer - e.g. CLI shouldn't have flags, core will probably have a lot, and I'd be surprised to see flags for store layer. Stuff like that | 12:55:02 |
| KFears (burning out) | In reply to @joepie91:pixie.town
so could you clarify whether this comment was intended to refer to "experimental features machinery" as a category, or specifically to the implementation of the concept that currently exists in cppnix/lix? Current impl, yes | 12:55:09 |
| joepie91 🏳️🌈 | ah okay, in that case I retract my earlier comments. I'd provisionally agree then, though I am uncertain how much of this is actually a fundamental technical/incentives problem, and how much of it exists purely on a governance level | 12:56:05 |
| joepie91 🏳️🌈 | there have been at least some cases in the history of cppnix where governance choices were made that were obviously the wrong answer for a feature that is genuinely experimental | 12:56:38 |
| joepie91 🏳️🌈 | (and that ended up ossifying the feature and making it de-facto stable) | 12:56:56 |
|  @qbit:tapenet.org left the room. | 16:11:10 |
|  TheFuzzball joined the room. | 18:10:39 |
 Jamie | repl-flake was a really annoying breaking change to a command which predates flakes | 21:00:28 |
| Jamie | i guess there should've been a nix-repl command all along but that never existed | 21:00:44 |
 ma27 | In reply to @jamie:memes.nz
i guess there should've been a nix-repl command all along but that never existed fwiw that existed in the pre 2.0 era, but was added to nix back then. | 21:01:08 |
