Haskell Foundation 2026 Update
discourse.haskell.org
discourse.haskell.org
Not mentioned in the update is that the Haskell Foundation is moving towards a model that already exists within the OCaml Foundation. The HF and OF have the same challenge: a shallow pool of (relatively) large sponsors.
Of course big successful firms have more money to contribute, and we are thankful for them. This move, whereby the HF will deploy more of its financial resources on technical challenges directly, is meant to attract the other 99.9% of firms using Haskell in production. Many firms, including my own employer, have a more tit-for-tat view of sponsorship.
If you have thoughts, or would like to get involved, do not hesitate to reach out to me! E-mail in bio
I have not played around with it to see how that plays out with agentic coding. But it does seem like an interesting idea.
Compact syntax is generally only a good thing for LLMs because it saves context windows and tokens.
As far as benchmarks go, I'd also like to see benchmarks that try to find what LLMs are good at. Most of the benchmarks seem designed to give LLMs hard problems and see if they can succeed. In that sense a "good" benchmark is one with a low pass rate.
But if we're going to do agentic coding we also need to know the opposite. We need to know which types of tasks given in which format LLMs will succeed at with like 95%+ accuracy. Then we can more easily build multi prompt pipelines with high confidence in each step.
- the tooling is decades behind, say, Rust or Go
- finding the right library in looks very different in Haskell--you frequently start with the signature on Hoogle. Agents can learn this but it's not the same as "web search"
- creating the right solution also looks different. It's usually borne out of thinking about the types and coming up with the correct algebra. Again models can probably learn to create the right types and orient the solution around that, but it's not automatic
- same today as yesterday, laziness is a blessing and a curse. The runtime can do unpredictable things when you suddenly evaluate a deep thunk
- GHC directives effectively mean there are multiple "Haskells"
Some of those are a result of the "avoid success at all costs" mantra. You can't shake that off in a day. It will take a concerted effort to make it more amenable for seamless adoption.
Haskell continues to be my favorite language to write and read, but Rust is the more practical language with a rich type system. If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript.
Laziness is hard to observe, maybe Strict and StrictData would become more popular in use within this context.
I haven't checked in a while now if effects have become the norm in the ecosystem, or if some solution exists for "string" types, but for me all of Haskell's expressivity is lost in the noise of endless conversion function, wrapper types when stacking monads, and import fiddling.
The problem you describe was solved more than a decade ago.
You use a Stackage snapshot (https://www.stackage.org/lts) which is a curation of packages that work together, similar to a Linux distribution like Debian, carrying one version per package.
Our company using Haskell has not spent 1 minute doing "dependency resolution" in the last 10 years, not has anybody we know.
I've been writing Haskell in production for almost 10 years now and manual dependency resolution has never been a thing.
If only Rust had something like GHCi.
Stack and Cabal have longer history than cargo, and Stackage for puzzle dependencies.
> - GHC directives effectively mean there are multiple "Haskells"
A bit like macro libraries and what features are enabled where in Rust
No way. Where vibe-coded Rust contains tons of "unsafe", you can have your vibe-coded Haskell sprinkled with "unsafePerformIO" and "unsafeCoerce" ;)
That's definitely not true, even if that was true maybe 6 years ago. As someone who's uses Haskell daily and also many other languages, I can see Haskell's tooling as more advanced than many others.
The progress has been in agreeing on a coherent interface everyone uses and which handles 99% of what most projects need with minimal friction.
Also there's no support for Android and iOS, atleast not without spending months in recompiling GHC with haskell.nix or other third party projects.
Eventually I switched to Rust. It's tooling is so mature that I can focus on developing than compiling GHC.
Despite these demerits, I love Haskell language and lazy eval. I wish I can use it one day.
Can AI not help speed this up?
As someone who DOESN'T use Haskell... What specifically is it missing?
Are you conflating ecosystem with tooling?
> If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript
Rust is quite expressive. Is Haskell really substantially much more?
I do think Rust is a great language for LLMs because I think expressiveness is key.
And yes, Haskell is significantly more expressive than Rust--at the cost of performance.
Having to enable them in the code is just a hassle. Just make it official and be done with it, just roll it into the language.
And those features are not a library that you just throw in, they are compiler specific.
the only other haskell compiler is MicroHs. and it has no pragmas. it just enables the whole thing.
this is not a real problem in practice. even without the GHC20XX stuff (which is nice). it feels like a problem a novice would point at (and be totally wrong)
sorry your favorite language doesn't let you import language features according to your needs. half of them have trade-offs! like -XOverloadedLists. Useful, but hurts inference. Maybe you don't want it globally. But maybe in a few modules, it's perfect. {-# LANGUAGE OverloadedLists -#} is the answer that no other mainstream lang has.
-XPolyKinds is another great example of that sort of extension.
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.
and this isn't even to mention stack..
now, if you're a not smart enough to handle there being many options existing in a world of trade-offs..haskell was never for you :)
And Haskell baking itself to Nix, also not sure if that is a good option. Try compiling that on say OpenBSD or FreeBSD.
For all the academic interest the language has, it seems very few of those people want to do anything foundational to make the language more ergonomic and more relevant.
Even without AI most of my Haskell time is spent thinking.
Also, I hand writing Haskell is one of my small after work pleasures.
* https://github.com/digitallyinduced/ihp/ is mainly written with Claude now
* https://jappie.me/haskell-vibes.html is gushing over agent-written Haskell
* https://discourse.haskell.org/t/anti-llm-sentiment-considere... huge thread about the divisiveness of LLM's from some person who loves using them with Haskell
I can see how agent coding is a nice fit for Haskell, since LLM's tend to be best at tasks where you can easily verify the output – and GHC lets you easily verify much more of your domain than say Python (sure you can test some of what dynamic typing doesn't catch, but LLM-written tests do not always do what you think they should[0]). At the same time, the LLMs tend to not code golf unless asked to, and they don't care if they have to wait for dependencies to compile, so that takes away the two major Haskell time sinks.
[0] https://haskellforall.com/2026/05/type-out-the-code#:~:text=...
The terseness of Haskell just hides the inherent complexity of the problem. The AI (or human) still needs to uncover that complexity in order to do non-trivial things.
[1] https://github.com/augustss/djinn
[2] http://lambda-the-ultimate.org/node/1178
AI did very good with it (both Opus 4.5 and GPT 5.4). It has a good time reasoning on compiler feedback and iterating for the reasons you mention.
But I still don't like Haskell and lisps for the very same reason: they don't scale.
Every single project out there needs to reinvent the wheel at language level (in form of compiler extensions or DSLs).
Makes the whole ecosystem hard to contribute and leverage.
People can keep saying how great lisps or Haskell are all they want, but the fact remains that very ugly languages everybody hates somehow can produce software so good that makes you adopting the language bearable.
There isn't a single software that makes me (personally) go "yeah, I want to learn Clojure/Racket/Haskell so I can use X".
Whereas stuff like Laravel or Rails or Redis or Unreal Engine can sell me on PHP, Ruby, C/Lua, C++ even though I'm not particularly fond of any of those languages.
To make this possible, the Haskell Foundation will remain without an executive director for the foreseeable future.
Instead of having a full-time employee in charge of fundraising, events, coordination, mediation and much more, we will split these responsibilities between the Board and a new, part-time role dedicated to the Haskell Foundation’s financial sustainability."
Sounds a great move in principle.
Source, seen it play out in a non-technical nonprofit that after years of stagnation, went the other way of hiring executive staff to run the day to day stuff. And from currently being part of another organization that is flailing that way presently.
He also reflected on his time and Haskell usage at Facebook here: https://www.youtube.com/watch?v=gEWBHP0PvRw&list=PLQpeDZt0_x...
I have experience where completely unmotivated (due to then ongoing very bad divorce) former Java programmer took a description of CPU for model code generation in Haskell's eDSL and successfully extended it in a month. The model had tricky (at the time) type level programming and type classes with associated types.
For example, one thing that is a friction point at my own job is knowledge of tooling for performance tuning and optimization. It's not that Haskell doesn't have this tooling, it's just not well-known.
Is there anything in particular you would need?
Maybe we should use Ai to generate up-to-date docs that are well organized like a book, so that all devs are more easy to conquer the different tools and flows.
For example, in C++, for basic toolchains LSP, formatters, standards of formatting, guidelines for performance, do and don’ts, … are more accessible.
I know it’s partially because of the size of the community. If we find a way to make the beginners, or experienced dev from other languages easier to start writing production code. We can thrive more.
Slow build times, deployment to Linux when developing on macos still pain. Deployment is pain specially on commodity VPS.
Go is very easy to cross compile and deploy.
But Haskell is better for a few things, but I've hardtime deploying it
Oh? Why is that?
Anytime I push to my Haskell repos my actions automatically create static binaries for installation on my nodes.
It's almost a one-liner + a nix derivation import, works within a minute on incremental builds even on large projects: https://input-output-hk.github.io/haskell.nix/tutorials/cros...
yes:
sh <(curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install)
> also many people are not familiar with nix and brew does all i need
it's a good reason to learn Nix then: it will completely replace your brew and offer an ultimate build tool suitable for any software stack moving forward. And you'll get cross-platform and static Haskell builds.
Our metrics are also showing that Haskell usage is actually growing. So overall, can't complain!
Are people targeting it as a runtime for Haskell as well?
The thing that's so elegant about Haskell is that it allows you to express programmatic constructs at a very abstract level. Abstraction is almost by definition difficult to grasp. That's why it takes a decade and a half for (most) people to go from arithmetic to calculus.