With sadness, I post:
Thoughts and discussion welcome.
13 Likes
Thanks for posting your thoughts.
I wonder whether using GHCi is an answer to the slow feedback loop?
If Python is a viable alternative then I imagine runtime performance isn’t the biggest concern?
2 Likes
I don’t feel like you take our concerns about the harm of AI seriously at all. The post is basically seems to be saying “so long, and thanks for all the fish”, but if the dolphins were the ones paying for the hyperspace bypass and thus the demolition of earth. It leaves a bitter taste in my mouth.
20 Likes
What a nice natural experiment, I’m eager to learn the results.
1 Like
that’s kind of AI in a nutshell, right? Explore and gobble up the sum total of human thought and labor and then go terminally Exploit
and tbh “X is leaving Haskell” in a nutshell too.
the world is especially full of FUD and FOMO nowadays. doubly so if you work at a company adjacent to the SV zeitgeist. so to be a Haskeller who still codes in plaintext is not easy. it’s existentially stressful, even!
it takes guts to be amazing
7 Likes
This is a great point. We are notably not moving Scarf Gateway (our main performance-critical system) off Haskell. Python indeed would not be a good fit there.
However, for general purpose web APIs, runtime performance of the language has not been nearly as relevant for us, compared to things like DB performance. I think this is true for a lot of companies.
GHCI is certainly faster, But it still doesn’t remove this cost when you look at things like CI or doing a lot of parallel work.
3 Likes
Nope. Scarf is cash flow positive and default-alive now. We are making the choices that work best for us!
4 Likes
Fair point – I think these concerns are understandable. And I am not trying to refute them! I am ultimately more focused here on the pragmatism of our team’s technology choices than I am about making moral judgements about the people, orgs, and practices behind those technologies.
3 Likes
I would be interested to hear more about the root causes of your long compile-times. In my experience, long compile-times are often a result of over using specific language features or architecting projects in an overly linear way, rather than something essential to Haskell.
But increasingly, that is not how I want to work. I want to spin up multiple worktrees, fork off different lines of work, let agents try things, review the results, and keep the useful ones. In that world, cold start time matters a lot.
Out of interest, did you try copying caches between worktrees? I do agree that you should optimize things so that your cold builds are also fast.
Haskell is in real danger.
AI is here to stay. The people and ecosystems that use it well are going to move much faster than the people and ecosystems that do not. I do not think this is subtle anymore. A skilled AI-powered engineer can now do work in days that used to take weeks or months.
I’m not sure I find this argument convincing. Haskell is a small community, if the relative productivity of the community was a problem then it should have already been wiped out by JS/C/etc.
It means caring about build times, onboarding, documentation, examples, tooling, agent workflows and marketing, more than we care about type system research. It means re-allocating community efforts and even abandoning current areas of work. It means finding ways for the Haskell Foundation to collect enough money to fund and coordinate more technical work.
I take your argument to be that the Haskell community doesn’t value AI so it doesn’t value these things. Yet, other than the explicit mention of “agent workflows”, everything here is valuable (perhaps even more so) for humans.
I think we have a long way to go in all of these areas, but I do think the majority of the Haskell community would like to see them improved. I’m also not sure if they are competing with type systems research (are these things actually in conflict).
I, for instance, care a lot about build times. I try to make things better in this area. But, I am limited by the amount of time I can dedicate to it. I imagine most people in the community feel similarly about many of the topics you mention.
31 Likes
I think the build time agentic thing is kinda circular? at least in my experience. maybe “circular” isn’t the right word, but lemme explain:
all my codebases that are neat and tidy and kept small and orthogonal don’t benefit from agentic coding. Because it’s so easy to just..write Haskell instead. Writing prompts and rigging up agents for these codebases is a giant chore and not worth the squeeze.
The only code I’ve been tempted to use agents for is giant hairballs that have slow compilation times. Because they’re also hard (or really, just unpleasant and annoying) to manually work with. But getting a slick agentic workflow for those small a large amount of work.
2 Likes
So I guess to generalize, AI agentic coding is most useful in codebases where coding is lower leverage. So if you change the language (to say idk Python), suddenly your code is lower leverage and AI def makes more sense!
2 Likes
This is an important difference. Small/hobby/single-person codebases vs large legacy systems with paying customers on the other side have very different requirements and tradeoffs.
it’s not just “worth the squeeze” for us, it’s so transformational to our economics that we’d be irrational to not lean into this new path.
This is kinda diminishing what I’m talking about actually. I am not talking about anything less than production codebases for real companies of real engineering teams that make real money. Not toys.
2 Likes
(sorry I accidentally clicked the flag button on this comment and can’t seem to un-flag?? hmm…)
We actually avoided fancy language extensions, template haskell, etc. Our compile times were long because there’s a lot of code to compile! and a lot of dependencies, etc. We spent a lot of time on caching, nix, etc. It’s like I said in the post. It’s just about how much work you have to put into building and maintaining this cache versus how often the cache misses, and how expensive those misses are.
I briefly looked at this. It wasn’t trivial. Probably it is possible, but I defer to my previous point.
By danger, I don’t mean that it will be wiped out. I mean that it won’t matter.
I hope to see many, many more people like you in the Haskell community then!
4 Likes
TH is actually faster than alternatives like Generics in my experience (but this sort of decision should always be backed up by benchmarks). I’m a bit sceptical that just the amount of code would be the root cause. Caching and fast builds are somewhat orthogonal. FWIW I think people tend to over-invest in caching rather than putting time into understanding performance both for build times and in general.
These are problems you will encounter in any language, eg, your test suite will get too slow, and then you’ll have to analyse where you are spending time.
Interesting! What do you mean by this?
2 Likes
Re. compile times, if you want to have a large Haskell code base and keep them under control, you absolutely need to minimize usage of type families (you can be more lenient about generics, but unless you know when, you should keep their usage to a minimum too).
This in particular excludes libraries such as beam (that you mentioned using). This one is known to obliterate compile times, I suspect this was the root of your issue.
I have an app at work that has 1200 modules, ~330k LoC, at -O0 it compiles locally for me under 3 minutes after cabal clean using 6 cores of a Ryzen 9950x3d (so you’d get maybe slightly longer times on significantly cheaper 9600x3d).
Re. LLMs, in my experience Haskell in an excellent target for LLM-assisted development, because it gives you tons of guard rails due to its type system. I find that agents are good with it too, I use mostly Claude Opus 4.8 and it produces good results for me either out of the box or after some prodding (Claude Fable 5 is even better).
I would understand switching to another statically typed language known for fast compile times, but I find the choice of Python (and any other dynamically typed language to be fair) if you want to heavily use LLMs baffling.
Lastly, I find the hardcore anti-LLM crowd in the community to be the vocal minority (as it usually is in such cases), most of us are busy getting on with our lives and using LLMs as the tools they are.
28 Likes
Right. We avoided Template Haskell back in 2020 when the story was much different than it is today. Template Haskell did indeed get a lot faster to copmpile. We eliminated generics wherever possible too. Problem still stood.
I mean it will have less of an impact on the world. That it won’t be a logical choice for people building companies or software that impacts people’s lives.
The mission of the Haskell Foundation, for instance is:
Amplify Haskell’s impact on humanity.
Haskell’s impact on humanity is not growing nearly as much as it could be!
2 Likes
Right – Beam was actually not something we were touching all that much by the end. Most of our data layer is click house these days, and we wrote our own library for that. There we could really focus on keeping compilation fast.
I definitely agree to this to some extent. It’s still problematic, I think, because it derails a lot of very useful discussion about where we should be going.
I’m curious, are you saying this compared to non-LLM enabled Haskell, or are you comparing this to LLM-enabled development in other languages? The comparison of the latter was very eye-opening for me and for our team.
Interesting. What kind of hit do you take in CI when you do have optimizations turned back on? If you have to throw this much power at a single build, are you able to add more builds in parallel with ease?
1 Like
We are able to run multiple agents in parallel and have them control different instances if ghci (ghciwath). It definitely helps agents iterate a lot faster.
1 Like
I can’t reconcile these two statements. You think it’s understandable that I think LLM use is a great threat to our community and society at large but you still think I’m derailing discussions about using LLMs?
4 Likes