I suppose it's a problem if the spec actually says they're monotonically incrementing because it's clear that isn't guaranteed. But that was never a property I wanted or expected out of them anyway.

All of the other issues here sound like misunderstandings or misuses of ids, IMHO

I've been self hosting Vaultwarden for me and my wife for years without issue. People like to tell others what they should and shouldn't do because they want to feel superior to others, I suppose.

It's especially strange since self hosting is, aside from the 'fun' aspect of it, about personal control. So this tsk tsk'ing from others about self hosting a password manager is especially ridiculous.

I'll just export my vault and move to KeepPass or something else?

If you have the time, I'm specifically interested in:

Are you really all only using a single agent/context window? Or do you still use a coding agent individually but have other domain, planning, etc conversations with the shared context?

What tooling and model(s) are you using to do this?

How big of a team are you doing it with?

How long did it take you to transition to this process before it felt good?

We're a Haskell shop (and have been for over 10 years now) and are finding agentic development with Haskell to work pretty damn well.

Cold compile times in Haskell are painful indeed. Our development practices don't really cause us to do that much - even with agents.

It's unclear to me if the development practices at Scarf that cause them to hit this pain often are worth it if it means giving up Haskell because the compile times are too bad. Maybe they are, but I don't think so.

Am I looking in the wrong place?

For me the issue is only unbearable when running fractional scaling, for some reason.

I'm going to try the branch mentioned in the sibling comment, though.

If you're suggesting that _every_ GHC extension is enabled then I think you don't really understand the implications of that. Many aren't compatible with each other in varying degrees, for one. They also exist on a wide range of stability and production readiness.

On the other hand, I agree that the extensions indeed hurt Haskell. Standardizing on them is absolutely necessary to survival for a team of even a modest size. GHC2021 and GHC2024 help to do this for the community at large.

The real "deep" change that I think would be best for Haskell is probably impossible - that would be for GHC to split into two compilers - one for production use and one for research. I don't even know HOW we'd do that but I think that's ultimately what us production users want in some form or another.

I've been writing Haskell in production for almost 10 years now and manual dependency resolution has never been a thing.

Your entire take is super strange and presumptive.

Last I checked BredOS was close to having a reasonable experience with it but I haven't had the time to poke at it again. Personally I'd prefer an Arch derivative like BredOS or FreeBSD. I don't really want to buy a GPU to put in it but it seems like that's my only option at the moment?