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.
I didn't invent this mitigation FWIW - I saw it mentioned in one or another thread about this by someone else - possibly on the big reddit thread on this topic, not sure.
I have perf issues with emacs-pgtk on a 4k screen on Wayland with Niri in both Emacs as a client and not. The issues appear with typing or scolling, the delay and lag become noticeable.
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.
As someone else mentioned, that's what GHC2021 and GHC2024 are for.
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.
Her blog has lots of quality content that's been featured on HN several times - well before AI writing became a thing. Not that you should necessarily know that but just strong evidence that your intuitions here are way off on so many levels.
Your entire take is super strange and presumptive.
Are you being willfully obtuse or do you actually believe that's true of everyone? There are so many reasons why someone might have a laptop in such a situation but not be able to use a hotspot on their phone - it's not even worth listing them.
This comes down to intentions versus results. Viewed through the lens of results the comment you're replying to is still correct: The result is incompetence. I'd argue that's the only lens that matters when you're on the receiving end of such work.
Yeah. I mean, I still hold out hope that enough of the driver support will get mainlined or just rolled into some distro I want to use that I can use it for _something_ but right now it just sits unplugged on my desk. :(
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?
Embarrassingly, I don't really understand Hyper. I have a Moonlander and AFAICT the firmware (or at least the Oryx configurator tool they provide) says Hyper is just a combination of the basic 4 - Alt+Shift+Ctrl+Meta. I'm pretty sure that's at least not historically true... but I don't have a whole lot of use for it so I haven't tried to wrap my head around what's going on there.
I imagine there's a "real" hyper modifier but I haven't attempted to use it. For my sake, since I use GUI Emacs I find that I have enough mappings without it (I'm also a dirty evil user). A friend makes extensive use of it because he primarily uses Emacs via a terminal and Hyper avoids all other terminal keybind conflicts he might otherwise run into. But, he uses X11, too so no PGTK Emacs even if/when he does run GUI Emacs.
I'll try to dig into this some though and see if I can (a) determine a way to map a "true" hyper to my keyboard and (b) use it in PGTK Emacs and follow up with you.
Glad to see a good write-up of Wayland issues. My day-to-day doesn't run into the vast majority of these problems so when I see people melt down over a single trivial seeming Wayland choice about window coordinates then I have a really hard time relating.
This post is a lot more relatable.
As an aside, regarding remote Emacs - I can attest that Waypipe does indeed work fantastically for this. Better than X11 ever worked over the network for me.
I, too, suffer from the pgtk is slow issue (only a 4k monitor though it's mitigable and manageable for me)
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.